What do people think of the idea of requiring all deprecations specifying a version that the feature will be removed in (which under our annual release cadence would be at least the third release from the start of the deprecation, hence the deprecation being public for 2 years)? And that we also follow through with that removal?
Now I'm not suggesting it **must** be in three feature releases. A deprecation could be set to Python 4 if people truly feel keeping the code is as easy it gets in terms of maintenance and there's enough usage to warrant such a potential indefinite deprecation/maintenance while keeping the code and docs alive (basically "there are better ways to do this, but this works fine, too, if you were already using it"). But what I am trying to avoid is the semi-regular discussion we seem to have of what is or is not reasonable to deprecate and leave versus deprecate and eventually remove because we didn't specify what the eventual plan was for a deprecation. Also feel like it would help users to know specifically what the plan is with a deprecation rather than wondering if something will get removed in the next feature release or not because we left off a specific removal version. If people are amenable to this idea I will update PEP 387 (which I plan to start a discussion about post-SC election) and I would also plan to add a warnings._deprecate() which I roughly outlined once at https://discuss.python.org/t/pendingdeprecationwarning-is-really-useful/1038/18. _______________________________________________ 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/BRA7G4UIGGW2X7YY55KQZBOGJEYNUV6O/ Code of Conduct: http://python.org/psf/codeofconduct/
