[Python-checkins] r43657 - peps/trunk/pep-0000.txt peps/trunk/pep-3001.txt (original) (raw)

georg.brandl python-checkins at python.org
Wed Apr 5 09:34:59 CEST 2006

Author: georg.brandl Date: Wed Apr 5 09:34:58 2006 New Revision: 43657

Added: peps/trunk/pep-3001.txt Modified: peps/trunk/pep-0000.txt Log: Add PEP 3001.

Modified: peps/trunk/pep-0000.txt

--- peps/trunk/pep-0000.txt (original) +++ peps/trunk/pep-0000.txt Wed Apr 5 09:34:58 2006 @@ -43,6 +43,7 @@ I 11 Removing support for little used platforms von Loewis I 12 Sample reStructuredText PEP Template Goodger, Warsaw P 347 Migrating the Python CVS to Subversion von Löwis

@@ -415,6 +416,7 @@ S 358 The "bytes" Object Schemenauer SR 666 Reject Foolish Indentation Creighton S 754 IEEE 754 Floating Point Special Values Warnes

Added: peps/trunk/pep-3001.txt

--- (empty file) +++ peps/trunk/pep-3001.txt Wed Apr 5 09:34:58 2006 @@ -0,0 +1,120 @@ +PEP: 3001 +Title: Procedure for reviewing and improving standard library modules +Version: RevisionRevisionRevision +Last-Modified: DateDateDate +Author: Georg Brandl <g.brandl at gmx.net> +Status: Draft +Type: Process +Content-Type: text/x-rst +Created: 05-Apr-2006 + + +Abstract +======== + +This PEP describes a procedure for reviewing and improving standard +library modules, especially those written in Python, making them ready +for Python 3000. There can be different steps of refurbishing, each +of which is described in a section below. Of course, not every step +has to be performed for every module. + + +Removal of obsolete modules +=========================== + +All modules marked as deprecated in 2.x versions should be removed for +Python 3000. The same applies to modules which are seen as obsolete today, +but are too widely used to be deprecated or removed. Python 3000 is the +big occasion to get rid of them. + +There will have to be a document listing all removed modules, together +with information on possible substitutes or alternatives. This infor- +mation will also have to be provided by the python3warn.py porting +helper script mentioned in PEP XXX. + + +Renaming modules +================ + +There are proposals for a "great stdlib renaming" introducing a hierarchic +library namespace or a top-level package from which to import standard +modules. That possibility aside, some modules' names are known to have +been chosen unwisely, a mistake which could never be corrected in the 2.x +series. Examples are names like "StringIO" or "Cookie". For Python 3000, +there will be the possibility to give those modules less confusing and +more conforming names. + +Of course, each rename will have to be stated in the documentation of +the respective module and perhaps in the global document of Step 1. +Additionally, the python3warn.py script will recognize the old module +names and notify the user accordingly. + + +Code cleanup +============ + +As most library modules written in Python have not been touched except +for bug fixes, following the policy of never changing a running system, +many of them may contain code that is not up to the newest language +features and could be rewritten in a more concise, modern Python. + +As long as these changes don't change the module's interface and behavior, +no documentation updates are necessary. + + +Enhancement of test coverage +============================ + +Code coverage by unit tests varies greatly between modules. Each test +suite should be checked for completeness, and the remaining classic tests +should be converted to PyUnit (or whatever new shiny testing framework +comes with Python 3000, perhaps py.test?). + +No documentation changes are necessary for this step. + + +Unification of module metadata +============================== + +This is a small and probably not very important step. There have been +various attempts at providing author, version and similar metadata in +modules (such as a "version" global). Those could be standardized +and used throughout the library. + +No documentation changes are necessary for this step, too. + + +Backwards incompatible bug fixes +================================ + +Over the years, many bug reports have been filed which complained about +bugs in standard library modules, but have subsequently been closed as +"Won't fix" since a fix would have introduced a major incompatibility +which was not acceptable in the Python 2.x series. In Python 3000, the +fix can be applied if the interface per se is still acceptable. + +Each slight behavioral change caused by such fixes must be mentioned in +the documentation, perhaps in a "Changed in Version 3.0" paragraph. + + +Interface changes +================= + +The last and most disruptive change is the overhaul of a module's public +interface. If a module's interface is to be changed, a justification +should be made beforehand, or a PEP should be written. + +The change must be fully documented as "New in Version 3.0", and the +python3warn.py script must know about it. + + +References +========== + +None yet. + + +Copyright +========= + +This document has been placed in the public domain.

More information about the Python-checkins mailing list