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