Ethan Furman wrote: > On 2020-01-23 07:20, Victor Stinner wrote: > > Python 3.9 introduces many small incompatible changes > > which broke tons > > On 2020-01-31 19:47, Mike Miller wrote: > > 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. > > 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. > > Petr Viktorin wrote: > > 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. > > As a user I would much rather know that my 3.2 code worked in every version > > of > 3.x, and not have to make changes in 3.5 and 3.7 and 3.11. Talk about death > by paper > cuts! I'd either be stuck updating already working code to get the benefits > of the latest > Python 3, or having multiple versions of Python 3 on my system. Both options > are > galling. > Having the latest Python 2, the latest Python 3, and the latest Python 4 is > much more > palatable.
Until you're being asked to maintain all of that for a decade. We paid a major price keeping Python 2 alive for over a decade. Now I'm not saying it wasn't the right thing to do considering what we changed, but for the stuff we are talking about removing it doesn't require a massive rewrite on the behalf of users. And we know from experience anything that is left in will get used no matter how loudly we try to broadcast that fact (and we know people still do not have a habit of running their code with warnings turned on). I think people also forget that prior to worrying about maintaining backwards-compatibility with Python 2 we deprecated for a release and then we removed (so an 18 month deprecation period). Python survived, users survived, and we all had more time for other things than trying to keep deprecated stuff from completely rotting out (look at inspect and trying to wedge keyword-only arguments into argspec() and friends as to prices paid to keeping stuff we would have shifted users off of as having a cost). And I know some people think that if we flat-out say we won't touch deprecated code that it should be enough, but even triaging issues for deprecated stuff as "won't fix" is still not free. _______________________________________________ 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/352ZQCOMN4YN7HHS5U2UK2B353M3CBCP/ Code of Conduct: http://python.org/psf/codeofconduct/
