[Python-3000] PEP 3108 - stdlib reorg/cleanup

Thu May 1 16:41:35 CEST 2008

On Mon, Apr 28, 2008 at 7:30 PM, Brett Cannon <brett at python.org> wrote:
> [bcc to stdlib-sig]
>> After two false starts over the YEARS of trying to cleanup and
> reorganize the stdlib, creating a SIG to get this going, having Guido
> give the PEP the once-over over the past several days, and creating
> two new bugs reports (issues 2715 and 2716), PEP 3108 is finally ready
> for public vetting!
>> While reading this PEP, do remember this is only about either removing
> modules, renaming them, or moving them into a package. Additions are
> not covered by this PEP!
>> Also realize all of the right people have been consulted on this stuff
> (e.g., the web SIG about the urllib package). So please do not think
> that something that seems drastic (e.g., the removal of all
> Mac-specific modules) was taken lightly when in fact the proper people
> were asked and they were okay with what is going on.
>> Lastly, I do not want this to turn into a drawn-out thread about how
> people think some module should stay because they happen to use it or
> suggest some other module to remove. Please think before you propose a
> change. I have been through this proposal process for this reorg
> before and every time it has gotten way out of control. I do not want
> it happen this time.
>> OK, with all of that out of the way, here is the PEP:
> -----------------------------------------------
>> PEP: 3108
> Title: Standard Library Reorganization
> Version: $Revision: 62573 $
> Last-Modified: $Date: 2008年04月28日 17:56:36 -0700 (2008年4月28日) $
> Author: Brett Cannon <brett at python.org>
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 01-Jan-2007
> Python-Version: 3.0
> Post-History:
>>> Abstract
> ========
>> Just like the language itself, Python's standard library (stdlib) has
> grown over the years to be very rich. But over time some modules
> have lost their need to be included with Python. There has also been
> an introduction of a naming convention for modules since Python's
> inception that not all modules follow.
>> Python 3.0 has presented a chance to remove modules that do not have
> long term usefulness. This chance also allows for the renaming of
> modules so that they follow the Python style guide [#pep-0008]_. This
> PEP lists modules that should not be included in Python 3.0 and what
> modules need to be renamed.
>>> Modules to Remove
> =================
>> Guido pronounced that "silly old stuff" is to be deleted from the
> stdlib for Py3K [#silly-old-stuff]_. This is open-ended on purpose.
> Each module to be removed needs to have a justification as to why it
> should no longer be distributed with Python. This can range from the
> module being deprecated in Python 2.x to being for a platform that is
> no longer widely used.
>> This section of the PEP lists the various modules to be removed. Each
> subsection represents a different reason for modules to be
> removed. Each module must have a specific justification on top of
> being listed in a specific subsection so as to make sure only modules
> that truly deserve to be removed are in fact removed.
>> When a reason mentions how long it has been since a module has been
> "uniquely edited", it is in reference to how long it has been since a
> checkin was done specifically for the module and not for a change that
> applied universally across the entire stdlib. If an edit time is not
> denoted as "unique" then it is the last time the file was edited,
> period.
>> The procedure to thoroughly remove a module is:
>> #. Remove the module.
> #. Remove the tests.
> #. Edit ``Modules/Setup.dist`` and ``setup.py`` if needed.
> #. Remove the docs (if applicable).
> #. Run the regression test suite (using ``-uall``); watch out for
> tests that are skipped because an import failed for the removed
> module.
>> If a deprecation warning is added to 2.6, it would be better to make
> all the changes to 2.6, merge the changes into the 3k branch, then
> perform the procedure above. This will avoid some merge conflicts.
>>> Previously deprecated
> ---------------------
>> PEP 4 lists all modules that have been deprecated in the stdlib
> [#pep-0004]_. The specified motivations mirror those listed in
> PEP 4. All modules listed
> in the PEP at the time of the first alpha release of Python 3.0 will
> be removed.
>> The entire contents of lib-old will also be removed. These modules
> have already been removed from being imported but are kept in the
> distribution for Python for users that rely upon the code.
>> * buildtools
>> + Documented as deprecated since Python 2.3 without an explicit
> reason.
>> * cfmfile
>> + Documented as deprecated since Python 2.4 without an explicit
> reason.
>> * cl
>> + Documented as obsolete since Python 2.0 or earlier.
> + Interface to SGI hardware.
>> * md5
>> + Supplanted by the ``hashlib`` module.
>> * mimetools
>> + Documented as obsolete without an explicit reason.
>> * MimeWriter
>> + Supplaned by the ``email`` package.
>> * mimify
>> + Supplanted by the ``email`` package.
>> * multifile
>> + Supplanted by the ``email`` package.
>> * posixfile
>> + Locking is better done by ``fcntl.lockf()``.
>> * rfc822
>> + Supplanted by the ``email`` package.
>> * sha
>> + Supplanted by the ``hashlib`` 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
> ----------------------------------
>> Python supports many platforms, some of which are not widely held.
> And on some of these platforms there are modules that have limited use
> to people on those platforms. Because of their limited usefulness it
> would be better to no longer burden the Python development team with
> their maintenance.
>> The module mentioned below are documented. All undocumented modules
> for the specified platforms will also be removed.
>> IRIX
> /////
> The IRIX operating system is no longer produced [#irix-retirement]_.
> Removing all modules from the plat-irix[56] directory has been deemed
> reasonable because of this fact.
>> + AL/al [done: 3.0]
>> - Provides sound support on Indy and Indigo workstations.
> - Both workstations are no longer available.
> - Code has not been uniquely edited in three years.
>> + cd [done: 3.0]
>> - CD drive control for SGI systems.
> - SGI no longer sells machines with IRIX on them.
> - Code has not been uniquely edited in 14 years.
>> + cddb [done: 3.0]
>> - Undocumented.
>> + cdplayer [done: 3.0]
>> - Undocumented.
>> + cl/CL/CL_old [done: 3.0]
>> - Compression library for SGI systems.
> - SGI no longer sells machines with IRIX on them.
> - Code has not been uniquely edited in 14 years.
>> + DEVICE/GL/gl/cgen/cgensuport [done: 3.0]
>> - GL access, which is the predecessor to OpenGL.
> - Has not been edited in at least eight years.
> - Third-party libraries provide better support (PyOpenGL [#pyopengl]_).
>> + ERRNO [done: 3.0]
>> - Undocumented.
>> + FILE [done: 3.0]
>> - Undocumented.
>> + FL/fl/flp [done: 3.0]
>> - Wrapper for the FORMS library [#irix-forms]_
> - FORMS has not been edited in 12 years.
> - Library is not widely used.
> - First eight hits on Google are for Python docs for fl.
>> + fm [done: 3.0]
>> - Wrapper to the IRIS Font Manager library.
> - Only available on SGI machines which no longer come with IRIX.
>> + GET [done: 3.0]
>> - Undocumented.
>> + GLWS [done: 3.0]
>> - Undocumented.
>> + imgfile [done: 3.0]
>> - Wrapper for SGI libimage library for imglib image files
> (``.rgb`` files).
> - Python Imaging Library provdes read-only support [#pil]_.
> - Not uniquely edited in 13 years.
>> + IN [done: 3.0]
>> - Undocumented.
>> + IOCTL [done: 3.0]
>> - Undocumented.
>> + jpeg [done: 3.0]
>> - Wrapper for JPEG (de)compressor.
> - Code not uniquely edited in nine years.
> - Third-party libraries provide better support
> (Python Imaging Library [#pil]_).
>> + panel [done: 3.0]
>> - Undocumented.
>> + panelparser [done: 3.0]
>> - Undocumented.
>> + readcd [done: 3.0]
>> - Undocumented.
>> + SV [done: 3.0]
>> - Undocumented.
>> + torgb [done: 3.0]
>> - Undocumented.
>> + WAIT [done: 3.0]
>> - Undocumented.
>>> Mac-specific modules
> ////////////////////
>> The Mac-specific modules are mostly unmaintained (e.g., the bgen
> tool used to auto-generate many of the modules has never been
> updated to support UCS-4). It is also not Python's place to maintain
> such a large amount of OS-specific modules. Thus all modules under
> plat-mac are to be removed.
>> A stub module for proxy access will be provided for use by urllib.
>> * _builtinSuites
>> - Undocumented.
> - Package under lib-scriptpackages.
>> * Audio_mac
>> - Undocumented.
>> * aepack
>> - OSA support is better through third-party modules.
>> * Appscript [#appscript]_.
>> - Hard-coded endianness which breaks on Intel Macs.
> - Might need to rename if Carbon package dependent.
>> * aetools
>> - See aepack.
>> * aetypes
>> - See aepack.
>> * applesingle
>> - Undocumented.
> - AppleSingle is a binary file format for A/UX.
> - A/UX no longer distributed.
>> * appletrawmain
>> - Undocumented.
>> * appletrunner
>> - Undocumented.
>> * argvemulator
>> - Undocumented.
>> * autoGIL
>> - Very bad model for using Python with the CFRunLoop.
>> * bgenlocations
>> - Undocumented.
>> * bundlebuilder
>> - Undocumented.
>> * Carbon
>> - Carbon development has stopped.
> - Does not support 64-bit systems completely.
> - Dependent on bgen which has never been updated to support UCS-4
> Unicode builds of Python.
>> * CodeWarrior
>> - Undocumented.
> - Package under lib-scriptpackages.
>> * ColorPicker
>> - Better to use Cocoa for GUIs.
>> * EasyDialogs
>> - Better to use Cocoa for GUIs.
>> * Explorer
>> - Undocumented.
> - Package under lib-scriptpackages.
>> * Finder
>> - Undocumented.
> - Package under lib-scriptpackages.
>>> * findertools
>> - No longer useful.
>> * FrameWork
>> - Poorly documented.
> - Not updated to support Carbon Events.
>> * gensuitemodule
>> - See aepack.
>> * ic
>> * icopen
>> - Not needed on OS X.
> - Meant to replace 'open' which is usually a bad thing to do.
>> * macerrors
>> - Undocumented.
>> * MacOS
>> - Would also mean the removal of binhex.
>> * macostools
>> * macresource
>> - Undocumented.
>> * MiniAEFrame
>> - See aepack.
>> * Nav
>> - Undocumented.
>> * Netscape
>> - Undocumented.
> - Package under lib-scriptpackages.
>>> * pimp
>> - Undocumented.
>> * PixMapWrapper
>> - Undocumented.
>> * StdSuites
>> - Undocumented.
> - Package under lib-scriptpackages.
>> * SystemEvents
>> - Undocumented.
> - Package under lib-scriptpackages.
>> * Terminal
>> - Undocumented.
> - Package under lib-scriptpackages.
>>> * terminalcommand
>> - Undocumented.
>> * videoreader
>> - No longer used.
>> * W
>> - No longer distributed with Python.
>>> .. _PyObjC: http://pyobjc.sourceforge.net/
>>> Solaris
> ///////
>> + SUNAUDIODEV/sunaudiodev [done: 3.0]
>> - Access to the sound card on Sun machines.
> - Code not uniquely edited in over eight years.
>>> Hardly used
> ------------
>> Some modules that are platform-independent are hardly used. This
> can be from how easy it is to implement the functionality from scratch
> or because the audience for the code is very small.
>> * audiodev [done: 3.0]
>> + Undocumented.
> + Not edited in five years.
> + If removed sunaudio should go as well (also undocumented; not
> edited in over seven 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 [done: 3.0]
>> + Function versions of the methods on string objects.
> + Obsolete since Python 1.6.
> + Any functionality not in the string object or module will be moved
> to the string module (mostly constants).
>> * symtable/_symtable
>> + Undocumented.
>> * toaiff [done: 3.0, moved to Demo]
>> + Undocumented.
> + Requires ``sox`` library to be installed on the system.
>> * user
>> + Easily handled by allowing the application specify its own
> module name, check for existence, and import if found.
>> * new [done: 3.0]
>> + Just a rebinding of names from the 'types' module.
> + Can also call ``type`` built-in to get most types easily.
> + Docstring states the module is no longer useful as of revision
> 27241 (2002年06月15日).
>> * pure [done: 3.0]
>> + Written before Pure Atria was bought by Rational which was then
> bought by IBM (in other words, very old).
>> * test.testall [done: 3.0]
>> + From the days before regrtest.
>>> Obsolete
> --------
>> Becoming obsolete signifies that either another module in the stdlib
> or a widely distributed third-party library provides a better solution
> for what the module is meant for.
>> * Bastion/rexec [done: 3.0]
>> + Restricted execution / security.
> + Turned off in Python 2.3.
> + Modules deemed unsafe.
>> * bsddb185 [done: 3.0]
>> + Superceded by bsddb3
> + Not built by default.
> + Documentation specifies that the "module should never be used
> directly in new code".
>> * commands
>> + subprocess module replaces it [#pep-0324]_.
> + Remove getstatus(), move rest to subprocess.
>> * compiler (need to add AST -> bytecode mechanism) [done: 3.0]
>> + Having to maintain both the built-in compiler and the stdlib
> package is redundant [#ast-removal]_.
> + The AST created by the compiler is available [#ast]_.
> + Mechanism to compile from an AST needs to be added.
>> * dircache
>> + Negligible use.
> + Easily replicated.
>> * dl [done: 3.0]
>> + ctypes provides better support for same functionality.
>> * fpformat
>> + All functionality is supported by string interpolation.
>> * htmllib
>> + Superceded by HTMLParser.
>> * ihooks
>> + Undocumented.
> + For use with rexec which has been turned off since Python 2.3.
>> * imageop [done: 3.0]
>> + Better support by third-party libraries
> (Python Imaging Library [#pil]_).
> + Unit tests relied on rgbimg and imgfile.
> - rgbimg was removed in Python 2.6.
> - imgfile slated for removal in this PEP. [done: 3.0]
>> * linuxaudiodev [done: 3.0]
>> + Replaced by ossaudiodev.
>> * mhlib
>> + Obsolete mailbox format.
>> * popen2 [done: 3.0]
>> + subprocess module replaces them [#pep-0324]_.
>> * sched
>> + Replaced by threading.Timer.
>>> * sgmllib
>> + Does not fully parse SGML.
> + In the stdlib for support to htmllib which is slated for removal.
>> * stat
>> + ``os.stat`` now returns a tuple with attributes.
> + Functions in the module should be made into methods for the object
> returned by os.stat.
>> * statvfs
>> + ``os.statvfs`` now returns a tuple with attributes.
>> * thread
>> + 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
> [#thread-deprecation]_.
>> * urllib
>> + Superceded by urllib2.
> + Functionality unique to urllib will be kept in the
> `urllib package`_.
>> * UserDict [done: 3.0]
>> + Not as useful since types can be a superclass.
> + Useful bits moved to the 'collections' module.
>> * UserList/UserString [done: 3.0]
>> + Not useful since types can be a superclass.
>>> Modules to Rename
> =================
>> Along with the stdlib gaining some modules that are no longer
> relevant, there is also the issue of naming. Many modules existed in
> the stdlib before PEP 8 came into existence [#pep-0008]_. This has
> led to some naming inconsistencies and namespace bloat that should be
> addressed.
>>> PEP 8 violations
> ----------------
>> PEP 8 specifies that modules "should have short, all-lowercase names"
> where "underscores can be used ... if it improves readability"
> [#pep-0008]_. The use of underscores is discouraged in package names.
> The following modules violate PEP 8 and are not somehow being renamed
> by being moved to a package.
>> ================== ==================================================
> Current Name Replacement Name
> ================== ==================================================
> _winreg winreg (rename also because module has a public
> interface and thus should not have a leading
> underscore)
> ConfigParser configparser
> copy_reg copyreg
> PixMapWrapper pixmapwrapper
> Queue queue
> SocketServer socketserver
> ================== ==================================================
>>> Merging C and Python implementations of the same interface
> ----------------------------------------------------------
>> Several interfaces have both a Python and C implementation. While it
> is great to have a C implementation for speed with a Python
> implementation as fallback, there is no need to expose the two
> implementations independently in the stdlib. For Python 3.0 all
> interfaces with two implementations will be merged into a single
> public interface.
>> The C module is to be given a leading underscore to delineate the fact
> that it is not the reference implementation (the Python implementation
> is). This means that any semantic difference between the C and Python
> versions must be dealt with before Python 3.0 or else the C
> implementation will be removed until it can be fixed.
>> One interface that is not listed below is xml.etree.ElementTree. This
> is an externally maintained module and thus is not under the direct
> control of the Python development team for renaming. See `Open
> Issues`_ for a discussion on this.
>> * pickle/cPickle
>> + Rename cPickle to _pickle.
> + Semantic completeness of C implementation *not* verified.
>> * profile/cProfile
>> + Rename cProfile to _profile.
> + Semantic completeness of C implementation *not* verified.
>> * StringIO/cStringIO [done: 3.0]
>> + Add the class to the 'io' module.
>>> No public, documented interface
> -------------------------------
>> There are several modules in the stdlib that have no defined public
> interface. These modules exist as support code for other modules that
> are exposed. Because they are not meant to be used directly they
> should be renamed to reflect this fact.
>> ============ ===============================
> Current Name Replacement Name
> ============ ===============================
> markupbase _markupbase [done: 3.0]
> dummy_thread _dummy_thread [#]_
> ============ ===============================
>> .. [#] Assumes ``thread`` is renamed to ``_thread``.
>>> Poorly chosen names
> -------------------
>> A few modules have names that were poorly chosen in hindsight. They
> should be renamed so as to prevent their bad name from perpetuating
> beyond the 2.x series.
>> ================= ===============================
> Current Name Replacement Name
> ================= ===============================
> repr reprlib
> test.test_support test.support
> ================= ===============================
>>> Grouping of modules
> -------------------
>> As the stdlib has grown, several areas within it have expanded to
> include multiple modules (e.g., dbm support). Thus some new packages
> make sense where the renaming makes a module's name easier to work
> with.
>>> dbm package
> ///////////
>> ================= ===============================
> Current Name Replacement Name
> ================= ===============================
> anydbm dbm.tools [1]_
> dbhash dbm.bsd
> dbm dbm.ndbm
> dumbdm dbm.dumb
> gdbm dbm.gnu
> whichdb dbm.tools [1]_
> ================= ===============================
>>> .. [1] ``dbm.tools`` can combine ``anybdbm`` and ``whichdb`` since the public
> API for both modules has no name conflict and the two modules have
> closely related usage.
>>>> html package
> ////////////
>> ================== ===============================
> Current Name Replacement Name
> ================== ===============================
> HTMLParser html.parser
> htmlentitydefs html.entities
> ================== ===============================
>>> http package
> ////////////
>> ================= ===============================
> Current Name Replacement Name
> ================= ===============================
> httplib http.client
> BaseHTTPServer http.server [2]_
> CGIHTTPServer http.server [2]_
> SimpleHTTPServer http.server [2]_
> Cookie http.cookies
> cookielib http.cookiejar
> ================= ===============================
>> .. [2] The ``http.server`` module can combine the specified modules
> safely as they have no naming conflicts.
>>> tkinter package
> ///////////////
>> ================== ===============================
> Current Name Replacement Name
> ================== ===============================
> Canvas tkinter.canvas
> Dialog tkinter.dialog
> FileDialog tkinter.filedialog [4]_
> FixTk tkinter._fix
> ScrolledText tkinter.scrolledtext
> SimpleDialog tkinter.simpledialog [5]_
> Tix tkinter.tix
> Tkconstants tkinter.constants
> Tkdnd tkinter.dnd
> Tkinter tkinter.__init__
> tkColorChooser tkinter.colorchooser
> tkCommonDialog tkinter.commondialog
> tkFileDialog tkinter.filedialog [4]_
> tkFont tkinter.font
> tkMessageBox tkinter.messagebox
> tkSimpleDialog tkinter.simpledialog [5]_
> turtle tkinter.turtle
> ================== ===============================
>> .. [4] ``tkinter.filedialog`` can safely combine ``FileDialog`` and
> ``tkFileDialog`` as there are no naming conflicts.
>> .. [5] ``tkinter.simpledialog`` can safely combine ``SimpleDialog``
> and ``tkSimpleDialog`` have no naming conflicts.
>>> urllib package
> //////////////
>> Originally this new package was to be named ``url``, but because of
> the common use of the name as a variable, it has been deemed better
> to keep the name ``urllib`` and instead shift existing modules around
> into a new package.
>> ================== ===============================
> Current Name Replacement Name
> ================== ===============================
> urllib2 urllib.request
> urlparse urllib.parse
> urllib urllib.parse, urllib.request [6]_
> ================== ===============================
>> .. [6] The quoting-related functions from ``urllib`` will be added
> to ``urllib.parse``. ``urllib.URLOpener`` and
> ``urllib.FancyUrlOpener`` will be added to ``urllib.request``
> as long as the documentation for both modules is updated.
>>> xmlrpc package
> //////////////
>> ================== ===============================
> Current Name Replacement Name
> ================== ===============================
> xmlrpclib xmlrpc.client
> SimpleXMLRPCServer xmlrpc.server [3]_
> CGIXMLRPCServer xmlrpc.server [3]_
> ================== ===============================
>> .. [3] The modules being combined into ``xmlrpc.server`` have no
> naming conflicts and thus can safely be merged.
>>> Transition Plan
> ===============
>> For modules to be removed
> -------------------------
>> For the removal of modules that are continuing to exist in the Python
> 2.x series (i.e., not deprecated explicitly in the 2.x series),
> ``warnings.warn3k()`` will be used to issue a DeprecationWarning.

FYI, we can also flag these using 2to3.
> Renaming of modules
> -------------------
>> For modules that are renamed, stub modules will be created with the
> original names and be kept in a directory within the stdlib (e.g. like
> how lib-old was once used). The need to keep the stub modules within
> a directory is to prevent naming conflicts with case-insensitive
> filesystems in those cases where nothing but the case of the module
> is changing.
>> These stub modules will import the module code based on the new
> naming. The same type of warning being raised by modules being
> removed will be raised in the stub modules.
>> Support in the 2to3 refactoring tool for renames will also be used
> [#2to3]_. Import statements will be rewritten so that only the import
> statement and none of the rest of the code needs to be touched. This
> will be accomplished by using the ``as`` keyword in import statements
> to bind in the module namespace to the old name while importing based
> on the new name.

You should cite the existing fix_imports fixer as one example of how
to do this: http://svn.python.org/view/sandbox/trunk/2to3/lib2to3/fixes/fix_imports.py?view=markup
> Open Issues
> ===========
>> Renaming of modules maintained outside of the stdlib
> ----------------------------------------------------
>> xml.etree.ElementTree not only does not meet PEP 8 naming standards
> but it also has an exposed C implementation [#pep-0008]_. It is an
> externally maintained package, though [#pep-0360]_. A request will be
> made for the maintainer to change the name so that it matches PEP 8
> and hides the C implementation.
>>> Rejected Ideas
> ==============
>> 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 basic
> usage.
>> * fileinput
>> + Useful when having to work with stdin.
>> * linecache
>> + Used internally in several places.
>> * nis
>> + Testimonials from people that new installations of NIS are still
> occurring
>> * getopt
>> + Simpler than optparse.
>> * repr
>> + Useful as a basis for overriding.
> + Used internally.
>> * telnetlib
>> + Really handy for quick-and-dirty remote access.
> + Some hardware supports using telnet for configuration and
> querying.
>> * 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 own
> package. This PEP will not address this issue as it has its own
> design issues (naming, does it deserve special consideration in import
> semantics, etc.). Everything within this PEP can easily be handled if
> a 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 themes
> appeared in the stdlib. In the past people have suggested introducing
> new packages to help collect modules that share a similar theme (e.g.,
> audio). An Open Issue was created to suggest some new packages to
> introduce.
>> In the end, though, not enough support could be pulled together to
> warrant moving forward with the idea. Instead name simplification has
> been chosen as the guiding force for PEPs to create.
>>> References
> ==========
>> .. [#pep-0004] PEP 4: Deprecation of Standard Modules
> (http://www.python.org/dev/peps/pep-0004/)
>> .. [#pep-0008] PEP 8: Style Guide for Python Code
> (http://www.python.org/dev/peps/pep-0008/)
>> .. [#pep-0324] PEP 324: subprocess -- New process module
> (http://www.python.org/dev/peps/pep-0324/)
>> .. [#pep-0360] PEP 360: Externally Maintained Packages
> (http://www.python.org/dev/peps/pep-0360/)
>> .. [#module-index] Python Documentation: Global Module Index
> (http://docs.python.org/modindex.html)
>> .. [#timing-module] Python Library Reference: Obsolete
> (http://docs.python.org/lib/obsolete-modules.html)
>> .. [#silly-old-stuff] Python-Dev email: "Py3k release schedule worries"
> (http://mail.python.org/pipermail/python-3000/2006-December/005130.html)
>> .. [#thread-deprecation] Python-Dev email: Autoloading?
> (http://mail.python.org/pipermail/python-dev/2005-October/057244.html)
>> .. [#py-dev-summary-2004年11月01日] Python-Dev Summary: 2004年11月01日
> (http://www.python.org/dev/summary/2004-11-01_2004年11月15日/#id10)
>> .. [#2to3] 2to3 refactoring tool
> (http://svn.python.org/view/sandbox/trunk/2to3/)
>> .. [#pyopengl] PyOpenGL
> (http://pyopengl.sourceforge.net/)
>> .. [#pil] Python Imaging Library (PIL)
> (http://www.pythonware.com/products/pil/)
>> .. [#twisted] Twisted
> (http://twistedmatrix.com/trac/)
>> .. [#irix-retirement] SGI Press Release:
> End of General Availability for MIPS IRIX Products -- December 2006
> (http://www.sgi.com/support/mips_irix.html)
>> .. [#irix-forms] FORMS Library by Mark Overmars
> (ftp://ftp.cs.ruu.nl/pub/SGI/FORMS)
>> .. [#sun-au] Wikipedia: Au file format
> (http://en.wikipedia.org/wiki/Au_file_format)
>> .. [#appscript] appscript
> (http://appscript.sourceforge.net/)
>> .. [#ast] _ast module
> (http://docs.python.org/lib/ast.html)
>> .. [#ast-removal] python-dev email: getting compiler package failures
> (http://mail.python.org/pipermail/python-3000/2007-May/007615.html)
>>> Copyright
> =========
>> This document has been placed in the public domain.
>>>> ..
> Local Variables:
> mode: indented-text
> indent-tabs-mode: nil
> sentence-end-double-space: t
> fill-column: 70
> coding: utf-8
> End:
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/collinw%40gmail.com
>