4 ms·
Naive question: does Python follow SemVer?
by 3JPLW 7y ago
Naive question: does Python follow SemVer?
- icegreentea2 7y agoNo. Python versioning pre-dates semver. That said, point releases (like 3.7.2 vs 3.7.1) are generally considered backwards compatible - they are suppose to "just be" bug fixes and security fixes. 3.x to 3.x+1 has no guarantees about backwards compatibility.
- eesmith 7y agoIt'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.
- 3JPLW 7y agoI 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!
- eesmith 7y ago"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.
- 3JPLW 7y agoMy 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.
- eesmith 7y agoYou'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.
- 3JPLW 7y agoThose 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.
- eesmith 7y agoI 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.
- OJFord 7y agoHow's that different from just writing `async`, without `eval`? i.e. if the string's static `eval` isn't doing anything?
- orf 7y agoThe 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.