> 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?
IMHO that really helps to reduce amount of discussions for choosing when to remove. Like should we remove it in 3.9 or we should wait to 3.10 etc. Also the consumers of that depracted parts will know the exact version they can't support if they'll continue using it. So big +1 from me On Wed, Nov 27, 2019, 9:43 PM Brett Cannon <br...@python.org> wrote: > 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/ >
_______________________________________________ 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/W24J7QWYLEBS7WB67IGTQV6QLD32TVRY/ Code of Conduct: http://python.org/psf/codeofconduct/
