python-peps/pep-0283.txt

PEP: 283
Title: Python 2.3 Release Schedule
Version: $Revision$
Author: Guido van Rossum
Status: Incomplete
Type: Informational
Created: 27-Feb-2002
Python-Version: 2.3
Post-History: 27-Feb-2002

Abstract

    This document describes the development and release schedule for
    Python 2.3.  The schedule primarily concerns itself with PEP-sized
    items.  Small features may be added until the first beta release.
    Bugs may be fixed until the final release.

    There is currently no complete schedule.  I plan to release alpha
    1 in 2002, and hope for a final release in the second quarter of
    2003.

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


Release Manager

    Guido van Rossum.


Open issues

    There are some issues that may need more work and/or thought
    before the final release (and preferably before the first beta
    release).  For example:

    - Set API issues; is the sets module perfect?

    - A nicer API to open text files, replacing the ugly (in some
      people's eyes) "U" mode flag.  There's a proposal out there to
      have a new built-in type textfile(filename, mode, encoding).
      (Shouldn't it have a bufsize argument too?)

    - Fredrik Lundh's basetime proposal:
      http://effbot.org/ideas/time-type.htm

    - New widgets for Tkinter???


Completed features for 2.3

    This list is not complete.  See Doc/whatsnew/whatsnew23.tex in CVS
    for more, and of course Misc/NEWS for the full list.

    - Tk 8.4 update.

    - The bool type and its constants, True and False (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 for
      2.3).

    - Extended slice notation for all built-in sequences.  The patch
      by Michael Hudson is now all checked in.

    - Speed up list iterations by filling tp_iter and other tweaks.
      See http://www.python.org/sf/560736; also done for xrange and
      tuples.

    - Timeout sockets.  http://www.python.org/sf/555085

    - Stage B0 of the int/long integration (PEP 237).  This means
      issuing a FutureWarning about situations where hex or oct
      conversions or left shifts returns a different value for an int
      than for a long with the same value.  The semantics do *not*
      change in Python 2.3; that will happen in Python 2.4.

    - Nuke SET_LINENO from all code objects (providing a different way
      to set debugger breakpoints).  This can boost pystone by >5%.
      http://www.python.org/sf/587993, now checked in.  (Unfortunately
      the pystone boost didn't happen.  What happened?)

    - Write a pymemcompat.h that people can bundle with their
      extensions and then use the 2.3 memory interface with all
      Pythons in the range 1.5.2 to 2.3.  (Michael Hudson checked in
      Misc/pymemcompat.h.)

    - Add a new concept, "pending deprecation", with associated
      warning PendingDeprecationWarning.  This warning is normally
      suppressed, but can be enabled by a suitable -W option.  (This
      has been added, but nothing uses it yet.)

    - Warn when an extension type's tp_compare returns anything except
      -1, 0 or 1.  http://www.python.org/sf/472523 

    - Warn for assignment to None (in various forms).

    - PEP 218  Adding a Built-In Set Object Type            Wilson

      Alex Martelli contributed a new version of Greg Wilson's
      prototype, and I've reworked that quite a bit.  It's in the
      standard library now as the module "sets", although some details
      may still change until the first beta release.  (There are no
      plans to make this a built-in type, for now.)

    - PEP 293  Codec error handling callbacks               D<>rwald

      Fully implemented.  Error handling in unicode.encode or
      str.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.)
      http://www.python.org/sf/578494

    - A modified MRO (Method Resolution Order) algorithm.  Consensus
      is that we should adopt C3.  Samuele Pedroni has contributed a
      draft implementation in C, see http://www.python.org/sf/619475
      This has now been checked in.

    - A new command line option parser.  Greg Ward's Optik package
      (http://optik.sf.net) has been adopted, convert to a single
      module named optparse.  See also
      http://www.python.org/sigs/getopt-sig/

    - A standard datetime type.  This started as a wiki:
      http://www.zope.org/Members/fdrake/DateTimeWiki/FrontPage A
      prototype was coded in nondist/sandbox/datetime/.  Tim Peters
      has finished the C implementation and checked it in.  While we
      may be tweaking the API during the alpha test period, I consider
      this module basically complete -- except for its documentation.


Planned features for 2.3

    Here are a few PEPs and other ideas under consideration, with
    comments in "parade of the PEPs" style.  Not all of these will be
    part of the final 2.3 release; we'll update the list as decisions
    crystallize.

    This is pretty much an unordered laundry list.  Please send
    feedback to python-dev@python.org; I hope to maintain this for the
    life of the 2.3 development process.

    - For a class defined inside another class, the __name__ should be
      "outer.inner", and pickling should work.

    - PEP 273  Import Modules from Zip Archives             Ahlstrom

      There's a patch at http://www.python.org/sf/492105; an updated
      patch at http://www.python.org/sf/645650; but my expectation is
      that this will be subsumed by the PEP 302 work.

    - PEP 302  New Import Hooks                             JvR

      This looks very promising.  See http://www.python.org/sf/652586

    - Documentation: complete the distribution and installation
      manuals.

    - Documentation: complete the documentation for new-style
      classes.

    - Look over the Demos/ directory and update where required.

    - New tests.

    - Fix doc bugs on SF.

    - Remove use of deprecated features in the core.

    - Document deprecated features appropriately.

    - Mark deprecated C APIs with Py_DEPRECATED.

    - Deprecate modules which are unmaintained, or perhaps make a new
      category for modules 'Unmaintained'

    - In general, lots of cleanup so it is easier to move forward.


Features unlikely to make it into Python 2.3

    - Decide on a clearer deprecation policy (especially for modules)
      and act on it.  For a start, see this message from Neil Norwitz:
      http://mail.python.org/pipermail/python-dev/2002-April/023165.html
      There seems insufficient interest in moving this further in an
      organized fashion, and it's not particularly important.

    - Provide alternatives for common uses of the types module;
      Skip Montanaro has posted a proto-PEP for this idea:
      http://mail.python.org/pipermail/python-dev/2002-May/024346.html
      There hasn't been any progress on this, AFAICT.

    - Use pending deprecation for the types and string modules.  This
      requires providing alternatives for the parts that aren't
      covered yet (e.g. string.whitespace and types.TracebackType).
      It seems we can't get consensus on this.

    - An iterator tools module featuring goodies from SML and Haskell?
      http://mail.python.org/pipermail/python-dev/2002-May/024418.html
      I haven't heard about this in ages.

    - Deprecate the buffer object.
      http://mail.python.org/pipermail/python-dev/2002-July/026388.html
      http://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

      I haven't heard from Jon Riehl since he moved to Chicago.

    - Add support for the long-awaited Python catalog.  Kapil
      Thangavelu has a Zope-based implementation that he demoed at
      OSCON 2002.  Now all we need is a place to host it and a person
      to champion it.

    - 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.  Jeremy
      has made a little progress with a new compiler, but it's going
      slow and the compiler is only the first step.  Maybe we'll be
      able to refactor the compiler in this release.  I'm tempted to
      say we won't hold our breath.  In the mean time, Oren Tirosh has
      a much simpler idea that may give a serious boost to the
      performance of accessing globals and built-ins, by optimizing
      and inlining the dict access:
      http://tothink.com/python/fastnames/

    - Lazily tracking tuples?
      http://mail.python.org/pipermail/python-dev/2002-May/023926.html
      http://www.python.org/sf/558745
      Not much enthusiasm I believe.

    - PEP 286  Enhanced Argument Tuples                     von Loewis

      I haven't had the time to review this thoroughly.  It seems a
      deep optimization hack (also makes better correctness guarantees
      though).

    - 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.



Local Variables:
mode: indented-text
indent-tabs-mode: nil
End: