Previously deprecated [done]

PEP 4 lists all modules that have been deprecated in the stdlib.The specified motivations mirror those listed inPEP 4. All modules listedin the PEP at the time of the first alpha release of Python 3.0 willbe removed.

The entire contents of lib-old will also be removed. These moduleshave already been removed from being imported but are kept in thedistribution for Python for users that rely upon the code.

• cfmfile
  • Documented as deprecated since Python 2.4 without an explicitreason.
• cl
  • Documented as obsolete since Python 2.0 or earlier.
  • Interface to SGI hardware.
• md5
  • Supplanted by thehashlib module.
• mimetools
  • Documented as obsolete in a previous version.
  • Supplanted by theemail package.
• MimeWriter
  • Supplanted by theemail package.
• mimify
  • Supplanted by theemail package.
• multifile
  • Supplanted by theemail package.
• posixfile
  • Locking is better done byfcntl.lockf().
• rfc822
  • Supplanted by theemail package.
• sha
  • Supplanted by thehashlib package.
• sv
  • Documented as obsolete since Python 2.0 or earlier.
  • Interface to obsolete SGI Indigo hardware.
• timing
  • Documented as obsolete since Python 2.0 or earlier.
  • time.clock() gives better time resolution.

Platform-specific with minimal use [done]

Python supports many platforms, some of which are not widely used ormaintained.And on some of these platforms there are modules that have limited useto people on those platforms. Because of their limited usefulness itwould be better to no longer burden the Python development team withtheir maintenance.

The modules mentioned below are documented. All undocumented modulesfor the specified platforms will also be removed.

Hardly used [done]

Some platform-independent modules are rarely used. There are a number ofpossible explanations for this, including, ease of reimplementation, verysmall audience or lack of adherence to more modern standards.

• audiodev
  • Undocumented.
  • Not edited in five years.
• imputil
  • Undocumented.
  • Never updated to support absolute imports.
• mutex
  • Easy to implement using a semaphore and a queue.
  • Cannot block on a lock attempt.
  • Not uniquely edited since its addition 15 years ago.
  • Only useful with the ‘sched’ module.
  • Not thread-safe.
• stringold
  • Function versions of the methods on string objects.
  • Obsolete since Python 1.6.
  • Any functionality not in the string object or module will be movedto the string module (mostly constants).
• sunaudio
  • Undocumented.
  • Not edited in over seven years.
  • Thesunau module provides similar abilities.
• toaiff
  • Undocumented.
  • Requiressox library to be installed on the system.
• user
  • Easily handled by allowing the application specify its ownmodule name, check for existence, and import if found.
• new
  • Just a rebinding of names from the ‘types’ module.
  • Can also calltype built-in to get most types easily.
  • Docstring states the module is no longer useful as of revision27241 (2002-06-15).
• pure
  • Written before Pure Atria was bought by Rational which was thenbought by IBM (in other words, very old).
• test.testall
  • From the days before regrtest.

Obsolete

Becoming obsolete signifies that either another module in the stdlibor a widely distributed third-party library provides a better solutionfor what the module is meant for.

• Bastion/rexec [done]
  • Restricted execution / security.
  • Turned off in Python 2.3.
  • Modules deemed unsafe.
• bsddb185 [done]
  • Superseded by bsddb3
  • Not built by default.
  • Documentation specifies that the “module should never be useddirectly in new code”.
  • Available externally fromPyPI.
• Canvas [done]
  • Marked as obsolete in a comment by Guido since 2000(seehttp://bugs.python.org/issue210677).
  • Better to use theTkinter.Canvas class.
• commands [done]
  • subprocess module replaces it (PEP 324).
  • Remove getstatus(), move rest to subprocess.
• compiler [done]
  • Having to maintain both the built-in compiler and the stdlibpackage is redundant[17].
  • The AST created by the compiler is available[16].
  • Mechanism to compile from an AST needs to be added.
• dircache [done]
  • Negligible use.
  • Easily replicated.
• dl [done]
  • ctypes provides better support for same functionality.
• fpformat [done]
  • All functionality is supported by string interpolation.
• htmllib [done]
  • Superseded by HTMLParser.
• ihooks [done]
  • Undocumented.
  • For use with rexec which has been turned off since Python 2.3.
• imageop [done]
  • Better support by third-party libraries(Python Imaging Library[11]).

  • Unit tests relied on rgbimg and imgfile.

    • rgbimg was removed in Python 2.6.
    • imgfile slated for removal in this PEP.

• linuxaudiodev [done]
  • Replaced by ossaudiodev.
• mhlib [done]
  • Should be removed as an individual module; usemailboxinstead.
• popen2 [done]
  • subprocess module replaces it (PEP 324).
• sgmllib [done]
  • Does not fully parse SGML.
  • In the stdlib for support to htmllib which is slated for removal.
• sre [done]
  • Previously deprecated; importre instead.
• stat [TODO need to move all uses over toos.stat()]
  • os.stat() now returns a tuple with attributes.
  • Functions in the module should be made into methods for the objectreturned by os.stat.
• statvfs [done]
  • os.statvfs now returns a tuple with attributes.
• thread [done]
  • People should use ‘threading’ instead.
    • Rename ‘thread’ to _thread.
    • Deprecate dummy_thread and rename _dummy_thread.
    • Move thread.get_ident over to threading.
  • Guido has previously supported the deprecation[8].
• urllib [done]
  • Superseded by urllib2.
  • Functionality unique to urllib will be kept in theurllib package.
• UserDict [done: 3.0] [TODO handle 2.6]
  • Not as useful since types can be a superclass.
  • Useful bits moved to the ‘collections’ module.
• UserList/UserString [done]
  • Not useful since types can be a superclass.
  • Moved to the ‘collections’ module.

Maintenance Burden

Over the years, certain modules have become a heavy burden uponpython-dev to maintain. In situations like this, it is better for themodule to be given to the community to maintain to free python-dev tofocus more on language support and other modules in the standardlibrary that do not take up an undue amount of time and effort.

• bsddb3
  • Externally maintained athttp://www.jcea.es/programacion/pybsddb.htm .
  • Consistent testing instability.
  • Berkeley DB follows a different release schedule than Python,leading to the bindings not necessarily being in sync with what isavailable.

PEP 8 violations [done]

PEP 8 specifies that modules “should have short, all-lowercase names”where “underscores can be used … if it improves readability”.The use of underscores is discouraged in package names.The following modules violatePEP 8 and are not somehow being renamedby being moved to a package.

Merging C and Python implementations of the same interface

Several interfaces have both a Python and C implementation. While itis great to have a C implementation for speed with a Pythonimplementation as fallback, there is no need to expose the twoimplementations independently in the stdlib. For Python 3.0 allinterfaces with two implementations will be merged into a singlepublic interface.

The C module is to be given a leading underscore to delineate the factthat it is not the reference implementation (the Python implementationis). This means that any semantic difference between the C and Pythonversions must be dealt with before Python 3.0 or else the Cimplementation will be removed until it can be fixed.

One interface that is not listed below is xml.etree.ElementTree. Thisis an externally maintained module and thus is not under the directcontrol of the Python development team for renaming. SeeOpenIssues for a discussion on this.

• pickle/cPickle [done]
  • Rename cPickle to _pickle.
  • Semantic completeness of C implementationnot verified.
• profile/cProfile [TODO]
  • Rename cProfile to _profile.
  • Semantic completeness of C implementationnot verified.
• StringIO/cStringIO [done]
  • Add the class to the ‘io’ module.

No public, documented interface [done]

There are several modules in the stdlib that have no defined publicinterface. These modules exist as support code for other modules thatare exposed. Because they are not meant to be used directly theyshould be renamed to reflect this fact.

Poorly chosen names [done]

A few modules have names that were poorly chosen in hindsight. Theyshould be renamed so as to prevent their bad name from perpetuatingbeyond the 2.x series.

Grouping of modules [done]

As the stdlib has grown, several areas within it have expanded toinclude multiple modules (e.g., support for database files). Itthus makes sense to group related modules into packages.

Issues

Issues related to this PEP:

• Issue 2775: Master tracking issue
• Issue 2828: clean up undoc.rst

For modules to be removed

For module removals, it is easiest to remove the module first inPython 3.0 to see where dependencies exist. This makes findingcode that (possibly) requires the suppression of theDeprecationWarning easier.

Renaming of modules

Support in the 2to3 refactoring tool for renames will be used to helppeople transition to new module names[9]. Import statements will be rewritten so that only the importstatement and none of the rest of the code needs to be touched. Thiswill be accomplished by using theas keyword in import statementsto bind in the module namespace to the old name while importing basedon the new name (when the keyword is not already used, otherwise thereassigned name should be left alone and only the module that isimported needs to be changed). Thefix_imports fixer is anexample of how to approach this.

Renaming of modules maintained outside of the stdlib

xml.etree.ElementTree not only does not meetPEP 8 naming standardsbut it also has an exposed C implementation. It is anexternally maintained package, thoughPEP 360. A request will bemade for the maintainer to change the name so that it matchesPEP 8and hides the C implementation.

Modules that were originally suggested for removal

• asynchat/asyncore
  • Josiah Carlson has said he will maintain the modules.
• audioop/sunau/aifc
  • Audio modules where the formats are still used.
• base64/quopri/uu
  • All still widely used.
  • ‘codecs’ module does not provide as nice of an API for basicusage.
• fileinput
  • Useful when having to work with stdin.
• linecache
  • Used internally in several places.
• nis
  • Testimonials from people that new installations of NIS are stilloccurring
• getopt
  • Simpler than optparse.
• repr
  • Useful as a basis for overriding.
  • Used internally.
• sched
  • Useful for simulations.
• symtable/_symtable
  • Docs were written.
• telnetlib
  • Really handy for quick-and-dirty remote access.
  • Some hardware supports using telnet for configuration andquerying.
• Tkinter
  • Would prevent IDLE from existing.
  • No GUI toolkit would be available out of the box.

Introducing a new top-level package

It has been suggested that the entire stdlib be placed within its ownpackage. This PEP will not address this issue as it has its owndesign issues (naming, does it deserve special consideration in importsemantics, etc.). Everything within this PEP can easily be handled ifa new top-level package is introduced.

Introducing new packages to contain theme-related modules

During the writing of this PEP it was noticed that certain themesappeared in the stdlib. In the past people have suggested introducingnew packages to help collect modules that share a similar theme (e.g.,audio). An Open Issue was created to suggest some new packages tointroduce.

In the end, though, not enough support could be pulled together towarrant moving forward with the idea. Instead name simplification hasbeen chosen as the guiding force for PEPs to create.