On Thu., 28 Nov. 2019, 4:43 am 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"). As long as it's optional, a new deprecation helper that automatically escalated to FutureWarning in X.Y.0a0, and an outright error in X.Y.0b0 seems like a good idea to me. (Escalating to errors as soon as the version number changes would be a problem from a development process point of view) If we don't add a helper API, then this sounds like a restatement of the status quo to me, rather than a change in policy. Cheers, Nick. >
_______________________________________________ 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/AR54K6HOS6IH5TSXLOOPJ5YM2YYSLURS/ Code of Conduct: http://python.org/psf/codeofconduct/
