On 2020-02-03 12:55, Thomas Wouters wrote:
On Mon, Feb 3, 2020 at 10:53 AM Petr Viktorin <encu...@gmail.com
<mailto:encu...@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.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/X5RBXEEB5BFPXGGGT2MTG4KZL3OBXQFD/
Code of Conduct: http://python.org/psf/codeofconduct/
