On 2020-02-03 01:50, Petr Viktorin wrote:
When the changes are rolled out gradually across minor releases, those that
cause unforeseen trouble in real-world code can be identified in the
alphas/betas, and rethought/reverted if necessary.
To be clear, my suggestion was to maintain gradual deprecations and warnings,
but have a single removal event at the start of a new version major number. So
there will be many years of betas and releases to haggle over.
Also, I believe it is possible to separate the "mechanically fixable" breaks
from larger changes in fundamentals. Few folks are willing to entertain or
stomach the latter at this point in the lifecycle of Python. If one happens to
occur, scheduling it for X.4 instead of X+1.0 doesn't help much, and may serve
to obscure it.
In some sense, distributing the breaks avoids potential/temporary bad press at
the cost of easy planning. However, it feels like a very regular, easy to
understand process should trump that in the long run.
As a refinement to the idea above, perhaps a sub rule could be added:
- No deprecations should appear in a X.9 release to give folks time
to prepare.
-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/A7DWXEXHIBQ24ZOMTJ55NYCWGFOHRPMS/
Code of Conduct: http://python.org/psf/codeofconduct/
