Why not ship any improvements you have immediately to the users?
Why not ship any improvements you have immediately to the users?
Stability and predictability are important. Porting code to new versions is not something I want to be continuously working on, and increasing the number of OS/language/library combinations to debug is painful.
Once a year sounds about right, with important bug and security fixes being pushed out when needed.
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.
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.And that's not to say it shouldn't be attempted!
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.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.
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.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.
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.
i.e. if the string's static `eval` isn't doing anything?
That being said, don’t do this. Check the version explicitly.
This is also what the JavaScript community is moving towards, both for the language specs where new features are "released" once they're ready (see: https://2ality.com/2015/11/tc39-process.html) and their respective implementations in browsers and Node.
As far a I can tell, those release processes (with many millions of users and full backwards compatibility going back to early beginnings of JavaScript) are neither unstable nor unpredictable.
The mechanics of quickly releasing language level changes, or standard library changes, or runtime changes in Python I feel do not fully map to that of the Javascript experience.
The language usage models are also very different. In the majority of Javascript use cases, I feel that you either fully control the runtime and code (like in a server, or something like Electron), or you have a fairly intelligent server determining what the runtime environment is and providing backwards compatibility shims for you (polyfills on browsers).
Certainly something like the first case exists for Python, but certainly the tooling for deploying onto arbitrary runtime and capabilities doesn't quite exist. Indeed, the Python packaging story is one of its weaknesses right now.
Python certainly could be made into something where the Javascript like process would work, but I'd certainly agree with anyone in the core Python development team who believed that they thought their energies could be focused better on other priorities.
"There will be one release per year and it will contain all features that are finished by a yearly deadline."
That seems to be what is going on here with Python. Most JS implementations have differing amounts of the early stage features they have implemented, and given their open source nature some of the Python implementations can do the same thing.
I feel like I'm missing your point but to me it looks like the languages are converging on broadly similar release processes.
Update: ok, as soon as a proposal reaches stage 4 it's considered finalized and part of the standard. A proposal can reach stage 4 at any time during the year. At that point browser vendors will start implementing those. https://flaviocopes.com/es2019/
Language updates that change the language I prefer once every 25-40 years.