On 2020-02-03 17:00, Brett Cannon 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 paths and such. The maintenance burden is low on these items. Also, due to skittishness, removals have drug out to five plus releases anyway. So, why the aversion to formalizing the process, instead of "winging it" every release? 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. Just like we're talking about here.
More broadly, an agile cadence is great for innovative apps, not so great for mature platforms. Platforms are supposed to provide stability and predictability, and the popular ones do.
-Mike