Hacker News Reader

Comment by 3JPLW | Hacker News Reader

My point is really an aside, but none of your examples actually require eval. Any code could have used `async = 1` directly as a variable, for example. And dynamic languages needn't support eval, though they typically do.

It's just a challenge with permissive languages that expose as much of their internals as Python, but a practical view could still be taken — for example, it could be possible to run all the test-suites of packages in the PyPI on a new version to test for breakages.

View on HN

You're right; code could have used 'async = 1' before.

Another technique is:

  try:
    import test_module
  except SyntaxError:
    ...
  except NameError:
    ...

Nonetheless, my point wasn't really to show that eval() was essential, only that any language which supports eval() will have these problems.

Is C a permissive language?

C99 added support for BCPL-style comments, causing

   int a = 1 //*  */ 2
                    ;

to give different behavior. C11 removed gets(), and broke code which just happened to define its own aligned_alloc() while also #including stdlib.h.

Those releases are 12 years apart and are definitely not using SemVer.

I’m not at all against breaking changes, nor am I trying to litigate which languages are harder to extend non-breakingly, I’m just surprised that there’s no compatibility guarantees between 3.x releases.

I meant that C example to get some insight on what you mean by "permissive language" and why that was important to the topic.

What language makes the compatibility guarantee you're looking for? I can't think of enough such languages to warrant being surprised about Python's behavior.

Reply on news.ycombinator.com