
Python adopts a 12-month release cycle - Tomte
https://lwn.net/Articles/803679/
======
raymondh
From my point of view, the Python release cycle presents several challenges in
terms of two-way communication with users.

Ideally, we want people to download the beta releases and give feedback on
their real world experience with new features while there is still time to
make changes. (That is almost the entire point of a beta-release accompanied
by a feature freeze).

Actual practice tends to fall short of the ideal for several reasons:

* Not many users download the beta and try out the features. On the bug tracker, we tend to get very little feedback on our beta releases.

* Some features land with little to no documentation (the walrus operator, for example). This makes it difficult for users to assess the feature.

* The PEP process is decisive. Once a PEP is approved, it is too late for developers to give feedback. The feature will happen regardless of user feedback.

* Downstream tooling needs time to update, so it is difficult to try out a beta when you can't get your dependencies to run (MyPy, Black, requests, etc).

~~~
robomartin
For me the walrus operator is an example of how things can take a turn for the
worse. It's a bad idea. I have yet to see any example that justifies its
existence. Put a different way, I have yet to see a reason for not extending
"=" to add this behavior. This is how a nice language can be ruined and can
become a Tower of Babel scenario. In some ways this is how J is a ruined
version of APL, because it completely destroys what the language was about in
the first place. Next thing we know we are going to end-up with 23 different
assignment operators, one for each chromosome pair.

The other part I don't get is the religious insistence against not
implementing something like a "switch" statement. This is one of the most
useful constructs in all of computer science and Python rejects it due to what
amounts to religious belief. In fact, one of the most powerful tools you get
when moving from assembler to C is the "switch()" statement. If you've ever
coded and maintained the equivalent in assembler you know exactly what I am
talking about.

Because, you know, a pile of "if" statements is somehow better. Ah, OK, with
"if" you can use data types other than integer. Sure, because we couldn't
define a Python "switch" to work with anything other than integers...like a
"switch" that could take a dictionary and route based on key/value matching,
etc.

Every single state machine I have written in who knows how many decades --in
C, C++, Objective-C, PHP, Verilog, etc.-- has had, at it's core, a single or
multi-layer "switch" statement. Can't do that in Python, 'cause.

<rant off>

~~~
joshuamorton
Using = for assignment expressions introduces ambiguity in if statements: is

    
    
        if (x = 3):
    

Intended, or not?

~~~
raymondh
There is no ambiguity. This example is invalid syntax.

~~~
joshuamorton
In Python yes, but the post I responded to asked why they settled on a
different assignment syntax for expressions.

It was to avoid that ambiguity (or error prone pattern, if you prefer) which
is present in, say, C.

~~~
ryl00
C/C++ compilers (at least, all the ones I know about) squawk about it unless
you add an additional set of parentheses around the assignment.

------
3JPLW
I was curious how this changed from their previous process. It looks like
they've historically averaged about once per 18 months for the past few
releases.

    
    
        3.4.0 — March 2014
        3.5.0 — Sept. 2015
        3.6.0 — Dec.  2016
        3.7.0 — June  2018
        3.8.0 — Oct.  2019
    

I'm not familiar with their release process — were those "scheduled" releases,
too, but just at 18 months (plus a little slop for release QA)? Or were they
just ready when they were ready?

~~~
vnglst
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 you have immediately to the users?

~~~
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
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
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
That's a great answer, thanks. I think it's really interesting to see how
differently both open source projects are managed and maintained.

------
AlexeyBrin
This is great if you code in pure Python! The problem is that every new Python
version seems to break something. Python 3.8 was released almost two weeks
ago, and some popular libraries still don't work with it, e. g. _SciPy_ ,
_Matplotlib_ , _OpenCV_ , _PyQt_ , _PySide2_ and probably a bunch of other
libraries that depend on the above.

~~~
takeda
That's not because 3.8 broke something. The packages you mentioned require
compiling. To make it simpler for users, the maintainers also provide
precompiled versions. The issue here is that no one precompiled them for 3.8
yet. You can still install them but you need to have compiler and their
dependencies installed.

The length of release cycle is irrelevant for this particular problem.

~~~
icegreentea2
Those packages do need re-compiling, but the official recompiles are blocked
by breakages in 3.8.

One of the issues blocking scipy release is a bug in 3.8's multiprocessing
library:
[https://bugs.python.org/issue38501](https://bugs.python.org/issue38501)

Technically they could probably patch around that in their test-suite... but
it really is regression in the language.

~~~
takeda
I see, I wasn't aware of that, my bad.

------
thewhitetulip
Can someone please shed some light on why 12 month release cycles are
necessary for a language?

Why would we want our language to constantly change?

~~~
inglor
Because objectively our languages are still quite awful and we still have a
ton of progress to make.

Look at Python or JavaScript or C++ 10 years ago. They each encompassed the
same philosophy they encompass today but lacked a lot of the ergnomics and
tooling that make them better languages.

Look at Go or Rust 5 years ago. Look at Java. We are constantly improving our
languages because improving a language is a great productivity win.

~~~
callesgg
Something can't be objectively awful.

Awful is a subjective descriptor.

~~~
inglor
There are several objective measures for programming language "awfulness". The
ones I've seen published the most in papers are:

\- Time to identify bugs in code

\- Defects in written software in fixed exercises

\- Defects in written software in real code

\- Time to develop a certain program

I can't say that the measurements of these is easy - but when we measure these
with old vs. new languages we see change.

One can claim something can't be "objectively good or bad" in the Popper sense
of science only caring about falsifiability or in the Quine sense of "just
predicting" but that becomes a philosophical argument and debate.

In my opinion since languages are how we express ourselves and we write code
in a _very_ roundabout way in many cases - languages are in fact objectively
awful, the number of defects is huge, development time is long and developer
experience is something few people deal with.

The literature on developer experience and programming language API is just
starting to emerge and we are still very very early on.

~~~
inglor
And of course all the research on this is pretty bad, on grad students /
biased samples and the methodology isn't great but it's better than nothing
and we should strive to improve it.

If anything that just shows how bad things are. (Although I believe they
really are improving)

------
ambivalence
Hi, Łukasz Langa here, author of PEP 602 which documents the change. I can
answer questions if you have any.

~~~
matt_LLVW
I like black. Thanks for black.

~~~
yhoiseth
Me too. Black is fantastic.

------
Alex3917
Full thread from the mailing list:

[https://www.prettyfwd.com/t/ERcYpP8xQt-
LG82eEoWB1Q/](https://www.prettyfwd.com/t/ERcYpP8xQt-LG82eEoWB1Q/)

------
willis936
Is there actual benefit to maintaining a language that isn’t backwards
compatible? I remember python being lauded as the best language ever 10 years
ago. Now, as I have to maintain several versions or face massive efforts to
port code, I dread working with it as much as national instruments. It’s not
just a little fractured. It’s fractured to its core to the point that just
having any system working feels like a miracle. Why are they steering the ship
into every possible rock?

~~~
Cyph0n
Are you referring to the Python 2 -> 3 fiasco? If so, I think that the Python
language committee will never make such a mistake again. They've seen first-
hand how difficult it is to get the ecosystem to move forward after a breaking
change like that.

But within Python 3, I think the deprecation system is decent. As far as I
know, it really only occurs with "uncommon" APIs, so the vast majority of code
will continue to work as expected on later Python 3 versions.

~~~
kstrauser
I don't think it was a mistake. There were some intractably difficult, "rip-
the-band-aid-off" types of changes that had to happen at some point. The PSF
decided that 3.0 was the right time to make those one-time changes so that
future migrations could be as small as possible.

~~~
cft
Then why didn't they remove GIL? Given the end of Moore's law and Python's
performance, this alone would have justified the discontinuity.

~~~
dickeytk
I would argue the GIL is a feature put in place to make it easier to write
parallel code.

If you want to do this in a more performant way you should be looking at a
different language.

People talk about the GIL as if it’s just some drawback that could be removed
and everything would be faster. There is a very good reason why it’s there.

~~~
masklinn
> I would argue the GIL is a feature put in place to make it easier to write
> parallel code.

It doesn't do that though. The GIL protects _interpreter internals_. It
doesn't make Python code thread-safe, although it does make various operations
atomic:

* native calls (which doesn't release the GIL) * individual bytecode instructions (which don't call into more python code)

The latter can make it seem like it magically protects your code, but even a
simple method call is at least 3 instructions (LOAD_FAST, LOAD_METHOD and
CALL_METHOD). Each instruction is atomic and the method call will be _if it 's
a native call_ (e.g. dict.get) but that's it, the entire call itself is not
atomic and you could thread-switch between LOAD_FAST and LOAD_METHOD, or
LOAD_METHOD and CALL_METHOD.

~~~
dickeytk
You just explained a bunch of implementation details but at the end of the day
my point remains: _having the GIL makes it easier to write parallel code_. I
didn't say it magically makes everything threadsafe.

~~~
masklinn
> having the GIL makes it easier to write parallel code.

It does not. What it does is _create a bigger trap_ , because the code _looks_
to be working in more testing situations, and will be more difficult to debug
when it starts failing.

------
droithomme
It's much better for things to be released when they are ready than on an
artificial and completely arbitrary cycle, brutally enforced.

------
elisharobinson
i think type obsession should stop . And more effort should be placed on
performance optimization of exiting apis. but there is lot to be learned from
LTS lifestyle of other products like debian and redhat which allow community
to be built around them.

~~~
rumanator
> I think type obsession should stop .

Typelessness is the bane of Python. The community would be wise to finally
take it seriously instead of keep pretending that type checking wouldn't fix
whole classes of the bugs and lead to safer software, higher productivity, and
overal better dev experience.

~~~
marviel
Yeah, I consider myself an advanced & "bought in"python programmer, but
recently I've been dabbling in VSCode + Typescript and it is truly amazing how
much more _confident_ I am in the things I create, when I'm careful to use the
type system and things like Union Types to my advantage.

Python typing still lags behind, and my python code is the scarier for it.

Also -- one gamechanger for me has been the addition of an IDE as the go-to
environment for programming in strongly typed languages... having an IDE that
"gets" the language you're coding in, and its types, has allowed me to eschew
a huge number of my "todo" statements altogether -- as I'll add a signature /
typename where I'm going to use it, and the compiler won't let you do
_anything_ until you've actually done what you asserted you were going to do.

~~~
takeda
I use python's type annotations, but didn't use TypeScript, what kind of
things you mean when saying that Python lags behind?

~~~
tomnipotent
Python doesn't have a transpilation stage like TypeScript, which gives JS a
sort of compile-time check that forces the developer to fix type errors.
Python type hints can just be ignored.

~~~
takeda
That's a really silly argument.

"TypeScript is better because I'm required to run the transplier"

If you believe that type checking is necessary, you won't have problem running
mypy.

Also TypeScript has a transplier, because there was no other option, browsers
use JavaScript and don't understand TypeScript so the conversion is necessary.
Maybe that won't be needed in the future, but it is needed now.

~~~
cwyers
A lot of people don't only work on their own code. They have dependencies,
they have coworkers, they have to work on code they wrote nine months ago. So
it's not "I need to be forced to use the type checker," it's "everybody needs
to be forced to use the type checker."

~~~
takeda
If it's required, you add mypy to your CI. Have it run whenever a PR is
submitted.

------
stanislavb
Welcome to the world of Ruby. It has a new major release every Christmas. On
the day.

------
badrabbit
Whatever you write in python,you must commit to maintaining it yearly. If you
write software and people buy it,you have to update it once in a while.

There are many use cases where this won't fly and it's fine to use something
more standardized and stabilized. They should have done this a long time ago
to avoid the 2.x -> 3.x headache.

Undesirable for those of us that sorta depend on stackoverflow answers to get
a lot of things done but I am sure there's a bigger picture the python devs
are seeing.

