[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