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 defined schedule.  We hope to release at
    least the first alpha before OSCON 2002, and the final release
    before the end of 2002, but if important projects below are
    delayed, the release may be delayed.

    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

    Barry Warsaw.  (Didn't have his finger on his nose in time. :)


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.  (There's also a bunch of things already implemented,
    like bool, PyMalloc, and universal newlines.)

    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.

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

    - PEP 269  Pgen Module for Python                       Riehl

      I haven't heard from Jon Riehl, so I consider dropping this idea.

    - PEP 273  Import Modules from Zip Archives             Ahlstrom

      I think this is close -- maybe it's already checked in and I
      don't know about it!

    - PEP 282  A Logging System                             Mick

      Vinay Sajip has been making steady progress on an
      implementation, and despite a recent near-flamewar (which I
      haven't followed) I expect that his code will be incorporated in
      the near future.

    - A new command line option parser.  Greg Ward's Optik
      (http://optik.sf.net) would fit the bill fine; there's only some
      question about whether it should be given a less "cutesy" name.
      See also http://www.python.org/sigs/getopt-sig/

    - 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

    - Extended slice notation for all built-in sequences.  A patch by
      Michael Hudson has solved this, mostly; there's an open issue
      about slice assignments where the source has a different length
      than the destination, as in L[:5:] = range(10).

    - An iterator tools module featuring goodies from SML and Haskell?
      http://mail.python.org/pipermail/python-dev/2002-May/024418.html

    - Speed up list iterations by filling tp_iter and other tweaks?
      http://www.python.org/sf/560736  (This is done; also for xrange.)

    - Fix the buffer object???
      http://mail.python.org/pipermail/python-dev/2002-May/023896.html

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

    - Timeoutsocket.  Work in progress.
      http://mail.python.org/pipermail/python-dev/2002-May/024077.html
      http://www.python.org/sf/555085  (Most of this is done, but we
      still need to add a global timeout option.)

    - Making None a keyword.  Can't be done right away, but a warning
      would be a first step.
      http://mail.python.org/pipermail/python-dev/2002-April/023600.html
      Ditto for 'as', which has been a pseudo-keyword long enough.

    - Stage 2 of the int/long integration (PEP 237).  This mostly
      means warning about situations where hex, oct or shift of an int
      returns a different value than for the same value as a long.  I
      propose *not* to change the semantics this time; that will
      happen in the next release, still with a warning.  (I think the
      PEP misses this step, but it's necessary -- we can't just change
      the semantics silently without warning first.)  Does this need a
      __future__ statement???

    - Nuke SET_LINENO from all code objects (providing a different way
      to set debugger breakpoints).  This can boost pystone by >5%.
      (Tim Peters.)

    - 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 has done
      this; it's in Misc/pymemcompat.h.)

    - PEP 262  Database of Installed Python Packages        Kuchling

      Andrew is still hopeful that he'll implement this.

    - Add support for the long-awaited Python catalog.  Kapil
      Thangavelu is working on an implementation (he's planning a demo
      for OSCON 2002).  What else is needed?

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

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

    - A standard datetime type.  An implementation effort is under way:
      http://www.zope.org/Members/fdrake/DateTimeWiki/FrontPage
      Effbot and MAL have a proposal for a basic interface that all
      datetime types should implement, but there are some problems with
      UTC.  A decision needs to be made.

    - 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

    - Add a new concept, "pending deprecation", with associated
      warning PendingDeprecationWarning.  This warning is normally
      suppressed, but can be enabled by a suitable -W option.

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

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

    - Doc deprecated features appropriately

    - Move deprecated features under Py_DEPRECATED (or whatever is decided)

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


Copyright

    This document has been placed in the public domain.


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