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.