On: Python adopts a 12-month release cycle

[jrumbut]

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.

[vnglst → jrumbut]

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) 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 → vnglst]

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 → icegreentea2]

That's a great answer, thanks. I think it's really interesting to see how differently both open source projects are managed and maintained.

[jrumbut → vnglst]

From the (very nice) link:

"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.

[vnglst → jrumbut]

Ah my bad, I think that's the wrong link describing the old process. I remember a recent talk by Axel (author of that post) describing the new process where features are accepted as soon as they are done (i.e. stage 4). But I can't find any articles by him to back this up, so maybe my memory is failing me ;-)

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/

[nicoburns → jrumbut]

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 → jrumbut]

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.

[mbauman → jrumbut]

Naive question: does Python follow SemVer?

[icegreentea2 → mbauman]

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 → icegreentea2]

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.

[OJFord → eesmith]

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

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

[orf → OJFord]

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.

[mbauman → eesmith]

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 → mbauman]

"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.

[mbauman → eesmith]

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 → mbauman]

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.

[mbauman → eesmith]

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.

[eesmith → mbauman]

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.