8 ms·

I'm wondering why Python has such an slow release cycle? There are new Node.js releases on a weekly (and sometimes daily) basis. Why not ship any improvements

• jrumbut 7y ago
  I like a more stately release process for a language (compared to applications where I do love frequent releases). 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.
  • 3JPLW 7y ago
    Naive question: does Python follow SemVer?
    • icegreentea2 7y ago
      No. 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 ago
        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.
        • 3JPLW 7y ago
          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!
          • 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 ago
              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.
              • eesmith 7y ago
                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.
  • vnglst 7y ago
    Maybe releasing more often could improve stability and predictability? Isn't it like they say: if it hurts, do it more often. 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 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.
    • icegreentea2 7y ago
      Things to consider. Javascript has a much stronger separation between language specification, standard library, and runtimes than Python. The Javascript standard library is famously sparse, and there are multiple runtimes with significant usage and development. Python on the other hand has a much larger standard library to maintain, and effectively has only one runtime (yes, I love PyPy too, but realistically 99+% of runtimes are CPython). And they are all implemented by the same group. 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.
      • vnglst 7y ago
        That's a great answer, thanks. I think it's really interesting to see how differently both open source projects are managed and maintained.
  • nicoburns 7y ago
    I think release frequency and stability are pretty orthoganal. I haven't had a node upgrade break my code since 0.8 (which was obvious a pre-1.0 release). Likewise, Rust releases every 6 weeks and it's rock solid.
  • droithomme 7y ago
    I like bug fixes and security updates the day they are ready. Language updates that change the language I prefer once every 25-40 years.
• coldtea 7y ago
  Because people depend in Python for real work, and are not used to the platform play havoc with them and change under their feet every few months...