Mike Miller wrote:
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). Potentially up to a decade, often not. We seem to agree that these are most likely minor things like duplicate import
On 2020-02-03 17:00, Brett Cannon wrote: paths and such. The maintenance burden is low on these items.
Please be careful making that claim. Over my 16 years of helping manage this project I can tell you that claim is not universally true no matter how small and simple you think something is.
Also, due to skittishness, removals have drug out to five plus releases anyway.
That has been due to Python 2 compatibility which is about to no longer be a concern. Prior to Python 2 this was not the case.
So, why the aversion to formalizing the process, instead of "winging it" every release?
There is work to formalize it in PEP 387. We are just dealing with an odd case of Python 2 compatibility which is a one-off situation.
Why force devs/end-users to maintain state about what release is compatible or waste time on investigation? Really, this was solved decades ago. Everyone knows what to do when a major version number changes. Other language platforms are not afraid to change them, likely because the breaks were typically minor and not break-the-world events.
Python predates semver. Assume every feature/minor release potentially has a breaking change and we have (hopefully) been raising warnings to the user for the past two years about the breaking change coming.