Mailman 3 April 2008 - stdlib-sig

PEP 3108 - stdlib reorg/cleanup
by Brett Cannon 28 Apr '08

28 Apr '08

[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 (Mon, 28 Apr 2008) $ Author: Brett Cannon <brett(a)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. 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. 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:

1 0

textwrap module and hyphenation
by Sylvain Fourmanoit 19 Apr '08

19 Apr '08

I just noticed the textwrap module in the standard library will break and line-wrap hyphenated words given the opportunity: >>> from textwrap import wrap >>> wrap('yaba daba-doo', width=10) ['yaba daba-', 'doo'] I have two questions about that: 1) Wouldn't it be worth mentioning this in the Python Library Reference (or it is just too obvious)? 2) Wouldn't it be useful to have a simple way to turn it off? Something like: >>> from textwrap import wrap >>> wrap('yaba daba-doo', width=10, break_hyphenated_words=False) ['yaba', 'daba-doo'] Since proper line-wrapping of hyphenated words is language-dependent and can interact with other orthographic and typesetting practices, I think it would be nicer to have a documented way to turn it off completely. Granted, it's not hard to manually do either; on Python 2.5.2 (as well as on Python 2.6 r62386), it's just a matter of setting the "TextWrapper.wordsep_re" attribute to "re.compile('(\s+)')"... I think having a publicly documented attribute wouldn't hurt anyway. -- Sylvain <syfou(a)users.sourceforge.net> The IBM 2250 is impressive ... if you compare it with a system selling for a tenth its price. -- D. Cohen

3 2

Making the reorg work
by Brett Cannon 19 Apr '08

19 Apr '08

Now that April 15th has past, it's time to start thinking about how best to handle the reorg. I have some ideas on how to make it all work. For 2.6, the modules should be renamed. The old names should be maintained with stub modules that are kept in some directory, such as lib-old. This separate directory is needed since some modules are only changing their case and that will wreak havoc on case-insensitive file systems. There should also be a Python 3.0 warning about the named deprecation. For 3.0, we need a fixer that deals with imports. Using the 'as' keyword to prevent the code from needing to be changed in any way would be best. There are probably some fixers already that deal with import that might be available for tweaking to make it work for this situation. While we wait for Guido to pronounce on the PEP (probably late next week) we can start discussing this and getting stuff lined up. I personally don't know how much time I will have for this (dealing with a relationship ending and having to move because of it) so any and all help I can get for this will be appreciated. -Brett

4 5

renaming test_support
by Benjamin Peterson 12 Apr '08

12 Apr '08

Hi guys, I saw in the stdlib-reorg PEP that test.test_support should be renamed to just test.support. I've done at patch at issue 2621. -- Cheers, Benjamin Peterson

1 0

Choosing a name for simplejson
by Brett Cannon 12 Apr '08

12 Apr '08

So simplejson is going to be added to the stdlib (this came down from up high, which is why there has not been more of a discussion here). That means we need to choose a name. Obviously 'json' would work, but I am not sure if there is something better. Remember, we want simple so that if someone goes, "I wonder if Python has a JSON module", they can easily find it (which means no crazy package names). We might also act as quality control on the source code to make sure it is up to snuff based on PEP 8. -Brett

10 18

Re: [stdlib-sig] Choosing a name for simplejson
by John Millikin 11 Apr '08

11 Apr '08

On Thu, Apr 10, 2008 at 7:47 PM, Brett C. <bcannon(a)gmail.com> wrote: > No link; personal email. Key members of python-dev trump the SIG. =) > Very well. Here's an archive of my stdlib-inclusion branch for jsonlib, with implementations for Python 2.6 and 3.0. If you can, please include its unit tests and encoding autodetection into whatever version of simplejson you're working on. Not all of the tests will be useful, since some test error checking, but most should be applicable.

1 1

REMINDER: April 15th to get in module removal ideas
by Brett Cannon 10 Apr '08

10 Apr '08

This is just a friendly reminder that the list of modules/packages to remove are due by April 15th. -Brett

1 0

Py3K bsddb name query
by Mark Summerfield 10 Apr '08

10 Apr '08

Hi, I notice that in PEP 3108 the dbm modules are going to be in package dbm: New Old ----------- -------------------------------------------- dbm.tools anydbm + whichdb dbm.db db.hash (actually bsd db so presumably using bsddb.hashopen() behind the scenes?) dbm.ndbm dbm dbm.dumb dumbdbm dbm.gnu gdbm This leaves bsddb as a separate package. As far as I can tell bsddb is not so different from the others. I presume (although the documentation for bsddbobject.keys() denies it) that btopen() gives lexicographical ordering and rnopen() give insertion order ordering by keys, whereas hashopen() is unordered like a dict and like the other dbms provided. In any case the name dbm.db seems wrong to me (too generic when the others are specific to their dbm type), so at the least shouldn't dbm.db be renamed dbm.bsd? If consistency were wanted, dbm.bsd.open() could be a wrapper for dbm.bsd.hashopen() but only with filenname, flag and mode arguments so as to match the other dbms, and with dbm.bsd.hashopen(), dbm.bsd.btopen() and dbm.bsd.rnopen() and the other bsddb-specific functions available in the module as usual? -- Mark Summerfield, Qtrac Ltd., www.qtrac.eu

4 4

platform as part of sys (was pypy_vm)
by Jim Jewett 09 Apr '08

09 Apr '08

"M.-A. Lemburg" <mal(a)egenix.com> wrote: > > Le mardi 08 avril 2008 ? 13:42 -0400, Jim Jewett a ?crit : > >> If important information is in the interpreter-specific location, it > >> would be nice to know where that is. That could be a specific module > >> name, but a module-name-pattern might be enough. ... > We already have a way to identify the Python implementation and > it works for CPython, IronPython and Jython: > >>> import platform > >>> platform.python_implementation() > 'CPython' Great, assuming that the capitalization is still OK for a module name. But looking through platform convinced me that it really ought be part of the sys reorg. And it provides at least one pattern for dealing with stuff that doesn't make sense in some interpreter environments. For example, platform.dist() is defined as returning which *Linux* distribution is used. So on windows, the tuple contains empty strings. (Though I'm not sure why the libc_ver is also returning blanks.) -jJ

2 1

pypy_vm (was: Proposal: new "interpreter" module)
by Jim Jewett 08 Apr '08

08 Apr '08

"Benjamin Peterson" <musiccomposition(a)gmail.com> wrote: > On Mon, Apr 7, 2008 at 3:41 PM, Carl Friedrich Bolz <cfbolz(a)gmx.de> wrote: > > I think the idea is nice, but PyPy couldn't really expose a "pypy" > > module, since that is the namespace the implementation itself is living > > in. Maybe add a suffix to the implementation name? cpython_vm or so. > You can name your implementation specific module anything you want. We're > not forcing anybody else to use our naming scheme! :) Yes and no. If important information is in the interpreter-specific location, it would be nice to know where that is. That could be a specific module name, but a module-name-pattern might be enough. sys.interpreter=cpython (or pypy_js_43, or whatever is chosen) <==> cpython_vm (or pypy_js_43_vm) is the module for internals Also note that even the interpreter-specific modules will probably be somewhat related. Just because something is implementation-defined doesn't mean prevent implementations from making similar choices. For example, even if Jython chooses to limit recursion only through memory exhaustion, some pypy targets might use exactly the same limits as standard CPython -- in which case, the obvious names for them to use will match CPython. -jJ

3 2