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
_______________________________________________
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/S7JXBK7OA75GVIVHDWOPMLALMCJJKGZN/
Code of Conduct: http://python.org/psf/codeofconduct/
