On 29 January 2016 at 21:59, Serhiy Storchaka <storch...@gmail.com> wrote: > On 29.01.16 21:56, Ezio Melotti wrote: >> On Fri, Jan 29, 2016 at 8:00 PM, Serhiy Storchaka <storch...@gmail.com> >> wrote: >>> Some deprecation can be documentation-only. >> >> Do you have examples where this has been done? > > An attribute of a module. [. . .] > Removing some special behavior [. . .]
Sometimes people want to avoid raising a DeprecationWarning even where it is technically possible. For example, the optparse module <https://bugs.python.org/issue25521>, which is still widely used in other modules. Brett’s load_module() situation also sounds similar. [Serhiy] > We already added DeprecationWarnings in bugfix releases of 2.7 (but only > enabled using the ``-3`` flag). There is no such mechanism for backporting > warnings in 3.x, but there is a need. I'm interesting wherever using > PendingDeprecationWarning instead of DeprecationWarnings is good enough for > this as well as they are less intrusive. [Ezio] >> 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. Perhaps we could (re)purpose PendingDeprecationWarning to mean “This may not be the best API to use, but there is no immediate plan to remove it”. It could go into bug fix releases as Serhiy suggested. A full DeprecationWarning would mean “Get your code in order; this API will be removed soon!”. >>> When use ``deprecated`` and when use ``deprecated-removed``? >> >> If we agree to always specify when the API will be removed, then we >> won't need to use "deprecated" anymore. >> If we want to keep using indefinite deprecations we will use it for them. >> >> This should be specified in the PEP once we reach a consensus. > > May be define that the "deprecated" directive has term to next change of > mayor version number (Python 4 currently)? It can be prolonged further, but > the existing of the API beyond this term shouldn't be expected. I thought Python 4 was mainly a myth or fantasy at this stage? _______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
