Abstract

This document describes the development and release schedule forPython 2.3. The schedule primarily concerns itself with PEP-sizeditems. Small features may be added up to and including the firstbeta release. Bugs may be fixed until the final release.

There will be at least two alpha releases, two beta releases, andone release candidate. Alpha and beta releases will be spaced atleast 4 weeks apart (except if an emergency release must be madeto correct a blunder in the previous release; then the blunderrelease does not count). Release candidates will be spaced atleast one week apart (excepting again blunder corrections).

Release Manager

Barry Warsaw, Jeremy Hylton, Tim Peters

Completed features for 2.3

This list is not complete. SeeDoc/whatsnew/whatsnew23.tex in CVSfor more, and of courseMisc/NEWS for the full list.

• Tk 8.4 update.
• Thebool type and its constants,True andFalse (PEP 285).
• PyMalloc was greatly enhanced and is enabled by default.
• Universal newline support (PEP 278).
• PEP 263 Defining Python Source Code Encodings, Lemburg

  Implemented (at least phase 1, which is all that’s planned for2.3).

• Extended slice notation for all built-in sequences. The patchby Michael Hudson is now all checked in.
• Speed up list iterations by fillingtp_iter and other tweaks.Seehttps://bugs.python.org/issue560736; also done forxrange andtuples.
• Timeout sockets.https://bugs.python.org/issue555085
• Stage B0 of theint/long integration (PEP 237). This meansissuing aFutureWarning about situations wherehex oroctconversions or left shifts returns a different value for anintthan for along with the same value. The semantics donotchange in Python 2.3; that will happen in Python 2.4.
• NukeSET_LINENO from all code objects (providing a different wayto set debugger breakpoints). This can boostpystone by >5%.https://bugs.python.org/issue587993, now checked in. (Unfortunatelythepystone boost didn’t happen. What happened?)
• Write apymemcompat.h that people can bundle with theirextensions and then use the 2.3 memory interface with allPythons in the range 1.5.2 to 2.3. (Michael Hudson checked inMisc/pymemcompat.h.)
• Add a new concept, “pending deprecation”, with associatedwarningPendingDeprecationWarning. This warning is normallysuppressed, but can be enabled by a suitable-W option. Only afew things use this at this time.
• Warn when an extension type’stp_compare returns anything except-1, 0 or 1.https://bugs.python.org/issue472523
• Warn for assignment toNone (in various forms).
• PEP 218 Adding a Built-In Set Object Type, Wilson

  Alex Martelli contributed a new version of Greg Wilson’sprototype, and I’ve reworked that quite a bit. It’s in thestandard library now as the modulesets, although some detailsmay still change until the first beta release. (There are noplans to make this a built-in type, for now.)

• PEP 293 Codec error handling callbacks, Dörwald

  Fully implemented. Error handling inunicode.encode orstr.decode can now be customized.

• PEP 282 A Logging System, Mick

  Vinay Sajip’s implementation has been packagized and imported.(Documentation and unit tests still pending.)https://bugs.python.org/issue578494

• A modified MRO (Method Resolution Order) algorithm. Consensusis that we should adopt C3. Samuele Pedroni has contributed adraft implementation in C, seehttps://bugs.python.org/issue619475This has now been checked in.
• A new command line option parser. Greg Ward’s Optik package(http://optik.sf.net) has been adopted, converted to a singlemodule namedoptparse. See alsohttp://www.python.org/sigs/getopt-sig/
• A standarddatetime type. This started as a wiki:http://www.zope.org/Members/fdrake/DateTimeWiki/FrontPage. Aprototype was coded innondist/sandbox/datetime/. Tim Petershas finished the C implementation and checked it in.
• PEP 273 Import Modules from Zip Archives, Ahlstrom

  Implemented as a part of thePEP 302 implementation work.

• PEP 302 New Import Hooks, JvR

  Implemented (though the 2.3a1 release contained some bugs thathave been fixed post-release).

• A new pickling protocol. SeePEP 307.
• PEP 305 (CSV File API, by Skip Montanaro et al.) is in; this isthe csv module.
• Raymond Hettinger’sitertools module is in.
• PEP 311 (Simplified GIL Acquisition for Extensions, by MarkHammond) has been included in beta 1.
• Two newPyArg_Parse*() format codes, ‘k’ returns an unsigned Clong int that receives the lowerLONG_BIT bits of the Pythonargument, truncating without range checking. ‘K’ returns anunsigned C long long int that receives the lowerLONG_LONG_BITbits, truncating without range checking. (SF 595026; ThomasHeller did this work.)
• A new version of IDLE was imported from the IDLEfork project(http://idlefork.sf.net). The code now lives in theidlelibpackage in the standard library and theidle script is installedbysetup.py.

Planned features for 2.3

Too late for anything more to get done here.

Ongoing tasks

The following are ongoing TO-DO items which we should attempt towork on without hoping for completion by any particular date.

• Documentation: complete the distribution and installationmanuals.
• Documentation: complete the documentation for new-styleclasses.
• Look over theDemos/ directory and update where required (AndrewKuchling has done a lot of this)
• New tests.
• Fix doc bugs on SF.
• Remove use of deprecated features in the core.
• Document deprecated features appropriately.
• Mark deprecated C APIs withPy_DEPRECATED.
• Deprecate modules which are unmaintained, or perhaps make a newcategory for modules ‘Unmaintained’
• In general, lots of cleanup so it is easier to move forward.

Open issues

There are some issues that may need more work and/or thoughtbefore the final release (and preferably before the first betarelease): No issues remaining.

Features that did not make it into Python 2.3

• The import lock could use some redesign. (SF 683658.)
• Set API issues; is the sets module perfect?

  I expect it’s good enough to stop polishing it until we’ve hadmore widespread user experience.

• A nicer API to open text files, replacing the ugly (in somepeople’s eyes) “U” mode flag. There’s a proposal out there tohave a new built-in typetextfile(filename,mode,encoding).(Shouldn’t it have abufsize argument too?)

  Ditto.

• New widgets for Tkinter???

  Has anyone gotten the time for this?Are there any newwidgets in Tk 8.4? Note that we’ve got better Tix supportalready (though not on Windows yet).

• Fredrik Lundh’s basetime proposal:

  http://effbot.org/ideas/time-type.htm

  I believe this is dead now.

• PEP 304 (Controlling Generation of Bytecode Files by Montanaro)seems to have lost steam.
• For a class defined inside another class, the__name__ should be"outer.inner", and pickling should work. (SF 633930. I’m nolonger certain this is easy or even right.)
• reST is going to be used a lot in Zope3. Maybe it could becomea standard library module? (Since reST’s author thinks it’s toounstable, I’m inclined not to do this.)
• Decide on a clearer deprecation policy (especially for modules)and act on it. For a start, see this message from Neal Norwitz:https://mail.python.org/pipermail/python-dev/2002-April/023165.htmlThere seems insufficient interest in moving this further in anorganized fashion, and it’s not particularly important.
• Provide alternatives for common uses of thetypes module;

  Skip Montanaro has posted a proto-PEP for this idea:https://mail.python.org/pipermail/python-dev/2002-May/024346.html

  There hasn’t been any progress on this, AFAICT.

• Use pending deprecation for thetypes andstring modules. Thisrequires providing alternatives for the parts that aren’tcovered yet (e.g.string.whitespace andtypes.TracebackType).It seems we can’t get consensus on this.
• Deprecate thebuffer object.
  • https://mail.python.org/pipermail/python-dev/2002-July/026388.html
  • https://mail.python.org/pipermail/python-dev/2002-July/026408.html

  It seems that this is never going to be resolved.

• PEP 269 Pgen Module for Python, Riehl

  (Some necessary changes are in; thepgen module itself needs tomature more.)

• Add support for the long-awaited Python catalog. KapilThangavelu has a Zope-based implementation that he demoed atOSCON 2002. Now all we need is a place to host it and a personto champion it. (Some changes to distutils to support this arein, at least.)
• PEP 266 Optimizing Global Variable/Attribute Access, Montanaro

  PEP 267 Optimized Access to Module Namespaces, Hylton

  PEP 280 Optimizing access to globals, van Rossum

  These are basically three friendly competing proposals. Jeremyhas made a little progress with a new compiler, but it’s goingslow and the compiler is only the first step. Maybe we’ll beable to refactor the compiler in this release. I’m tempted tosay we won’t hold our breath. In the meantime, Oren Tirosh hasa much simpler idea that may give a serious boost to theperformance of accessing globals and built-ins, by optimizingand inlining the dict access:http://tothink.com/python/fastnames/

• Lazily tracking tuples?
  • https://mail.python.org/pipermail/python-dev/2002-May/023926.html
  • https://bugs.python.org/issue558745

  Not much enthusiasm I believe.

• PEP 286 Enhanced Argument Tuples, von Loewis

  I haven’t had the time to review this thoroughly. It seems adeep optimization hack (also makes better correctness guaranteesthough).

• Make ‘as’ a keyword. It has been a pseudo-keyword long enough.Too much effort to bother.

Copyright

This document has been placed in the public domain.