On 2020-02-03 12:55, Thomas Wouters wrote:
On Mon, Feb 3, 2020 at 10:53 AM Petr Viktorin <encukou@gmail.com <mailto:encukou@gmail.com>> wrote:
On 2020-01-31 19:47, Mike Miller wrote: > > On 2020-01-23 07:20, Victor Stinner wrote: > > Python 3.9 introduces many small incompatible changes which broke tons > > > There's a well-known and established way of signaling breaking changes > in software platforms—it is to increment the major version number. > > Rather than debating the merits of breaking code on 3.9 or 3.10, > wouldn't it make more sense to do it in a Python 4.0 instead? Well, > either of these strategies sound logical to me: > > - Python 4.0 with removal of all of the Python 3-era deprecations > - Continuing Python 3.1X with no breaks > > In other words, we should keep compatibility, or not. In any case, from > the looks of it these will be tiny breaks compared to the Unicode > transition.
The Unicode transition also looked very small back when 3.0 was planned. It only takes one such not-so-little thing to make a big breaking release like 3.0. And even if all the changes were little, I wouldn't want to inflict 10 years of papercuts at once.
I agree with the sentiment that gradual deprecations are more easily managed, this statement about Python 3.0 is not true. The unicode transition was never thought to be small, and that's *why* 3.0 was such a big change.
Alright, "very small" is an overstatement. But it did seem much smaller than it turned out to be. https://docs.python.org/3.0/whatsnew/3.0.html lists it as the last of the big breaking changes, while most of the porting efforts were spent on it.
We knew it was going to break everything, so we took the opportunity to break more things, like the behaviour of indexing bytestrings. (Bytestrings were even going to be *mutable* for a while.) I think we can all agree that it was a mistake, and that's certainly something we don't want to repeat: even if we defer actual removal of features for a x.0.0 release, it must not become carte blanche for breaking things. >
When the changes are rolled out gradually across minor releases, those that cause unforeseen trouble in real-world code can be identified in the alphas/betas, and rethought/reverted if necessary.
That's also the case if things are (loudly) deprecated *but not removed* until a x.0.0 release. The replacement would already be in use for years before the old way would go away.
I fear that this is only so if no unexpected issues come up. If we do a loud deprecation, how can we be sure we did it right?
Ethan Furman wrote: > I've gotta say, I like that plan. Instead of going to x.10, go to x+1.0. Every ten years we bump the major version and get rid of all the deprecations.
I don't. I hope the 10-year (and counting) transition from Python 2 to Python 3 will not become a tradition. I'd rather iterate on making removals less drastic (e.g. by making the DeprecationWarnings more visible). Iterate with a feedback loop, rather than do a one-time change and hope that everything goes well.