Nick Coghlan wrote: > 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.
The helper wouldn't be required, but I would say the message of when the removal will occur would be. And good idea about flipping in the beta stage. > (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. Well, it's an unspoken policy that I would like to write down. :) I would also then advocate to go into the code and docs and update it all to provide removal version targets. _______________________________________________ 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/B6IVFF6MXSLIQYPJWMA33QQ4C6427ZJP/ Code of Conduct: http://python.org/psf/codeofconduct/
