On Fri, 29 Jan 2016 at 11:57 Ezio Melotti <ezio.melo...@gmail.com> wrote:
> On Fri, Jan 29, 2016 at 8:00 PM, Serhiy Storchaka <storch...@gmail.com> > wrote: > > On 29.01.16 19:11, Ezio Melotti wrote: > [SNIP] > >> Deprecation Process > >> =================== > >> > >> These are the steps required to deprecate and remove an API: > >> > >> 1. propose to deprecate an API on a tracker issue or on python-dev > >> and decide in which version it will be removed. > >> > >> 2. attach to the issue a patch to deprecate the API that: > >> > >> * adds a ``DeprecationWarning`` to the code > > > > > > Some deprecation can be documentation-only. > > > > Do you have examples where this has been done? > I don't see the point of telling doc readers that a feature is > deprecated but keeping the same information hidden to developers. If > the actual warnings cause some issue, then the issue should be > addresses (the issue of being noisy has already been addressed by > silencing them by default), but having doc-only deprecation warnings > seems inconsistent and potentially confusing. > I have an example. When the concept of create_module()/exec_module() came into being for importlib, we wanted to deprecate load_module(). The problem is that while we had worked out the new API, we had not figured out how best to update C extension modules yet to the new API. We knew that load_module() usage should be discouraged, but we didn't want to trigger a DeprecationWarning while the stdlib itself had not stopped using it. So we documented it as deprecated without raising a DeprecationWarning. -Brett
_______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
