Hacker News Reader

Comment by eesmith | Hacker News Reader

It's also very hard, in any language with "eval", to support new language features and backwards compatibility.

    try:
      eval("async")
    except NameError:
      print("pre-3.7")
    except SyntaxError:
      print("3.7 or later")

Similarly, eval("a@b") gives a NameError on newer Pythons, and SyntaxError on older.

View on HN

How's that different from just writing `async`, without `eval`?

i.e. if the string's static `eval` isn't doing anything?

The module would not be able to be imported due to the syntax error. Eval is required to make the module syntax correct.

That being said, don’t do this. Check the version explicitly.

I don't think that has anything to do with `eval`. It's just hard to do with a dynamic language.

And that's not to say it shouldn't be attempted!

"Eval" is one way to implement a dynamic language, so I'm confused by why you seem to write those as very distinct concepts.

Is it correct to interpret your last line as saying that Python should support SemVer?

If so, the only way to get SemVer is for every release to increment new major number, as every single one has backward incompatible behaviors going through eval.

  eval("a:=1") - SyntaxError before 3.8
  eval("async=1") - SyntaxError starting with 3.7
  eval("1_0") - SyntaxError before 3.6
  eval("a@b") - SyntaxError before 3.5, NameError after

It's true there are other ways for a dynamic language to trigger backwards compatibility issues than by going through eval(), but my goal was to give concrete examples of how difficult it would be for Python to make guarantee about backwards compatibility because eval() does exist.

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.

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