On Mon, Feb 3, 2020 at 10:53 AM Petr Viktorin <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. 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. > > > 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/CHMOFONIBAACIW5A5SNHLTV6A5BEQXYT/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Thomas Wouters <tho...@python.org> Hi! I'm an email virus! Think twice before sending your email to help me spread!
_______________________________________________ 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/2R5CKAZICLAGNENAEBN6Z4ZNZRLM7YGW/ Code of Conduct: http://python.org/psf/codeofconduct/
