[Tutor] Questions about the deprecation of standard library modules
Steven D'Aprano
steve at pearwood.info
Tue Apr 2 12:25:10 EDT 2019
On Sat, Mar 30, 2019 at 10:13:16PM -0500, boB Stepp wrote:
> So my main question is how does one know in which Python version a
> deprecated module will be removed? I'm not too concerned about the
> imp module, but _do_ want to know how the removal process works for
> deprecated standard library modules that I might be interested in.
The usual process goes something like this:
- after much discussion, the core developers agree to deprecate
a module;
- in a fit on enthusiasm, the docs are adjusted to note that the
module is deprecated;
- many years later, somebody remembers the deprecation note in
the docs, and wonders whether or not the module should finally
be removed;
- the module is changed to give a warning when used;
- some years after that, somebody asks what's going on with
the deprecated module, shouldn't it be removed by now?
- and the module is finally removed.
(Only half joking.)
In practice, it depends on the specific developer, and how good he or
she is at coming back to the module and removing it after a "suitable"
time. Suitable usually means a minimum of two releases, but it could be
as little as one in urgent cases; in *very special circumstances* a
module which is a security risk could be removed immediately, but that's
rare.
Its not unusual for everyone to forget to remove a deprecated feature or
module until long after it should have been removed, or to decide that
deprecation notice or not, too many people are still using it and so it
can't be removed.
On the other hand, its also not ususual for modules to be removed
promptly. Usually its:
- one or two releases silently marked as deprecation pending;
- one or two releases marked depreciation (active warning);
- and then removed.
--
Steven
More information about the Tutor
mailing list