python-peps/pep-0200.txt

PEP: 200
Title: Python 2.0 Release Schedule
Version: $Revision$
Owner: Jeremy Hylton <jeremy@beopen.com>
Python-Version: 2.0
Status: Incomplete


Introduction

    This PEP describes the Python 2.0 release schedule, tracking the
    status and ownership of the major new features, summarizes
    discussions held in mailing list forums, and provides URLs for
    further information, patches, and other outstanding issues.  The
    CVS revision history of this file contains the definitive
    historical record.

Tentative Release Schedule

    Aug. 14: All 2.0 PEPs finished / feature freeze
    Aug. 28: 2.0 beta 1
    Sep. 29: 2.0 final

Guidelines for submitting patches and making changes

    Use good sense when committing changes.  You should know what we
    mean by good sense or we wouldn't have given you commit privileges
    <0.5 wink>.  Some specific examples of good sense include:

    - Do whatever the dictator tells you.

    - Discuss any controversial changes on python-dev first.  If you
      get a lot of +1 votes and no -1 votes, make the change.  If you 
      get a some -1 votes, think twice; consider asking Guido what he 
      thinks. 

    - If the change is to code you contributed, it probably makes
      sense for you to fix it.

    - If the change affects code someone else wrote, it probably makes
      sense to ask him or her first.

    - You can use the SF Patch Manager to submit a patch and assign it
      to someone for review.

    Any significant new feature must be described in a PEP and
    approved before it is checked in.

    Any significant code addition, such as a new module or large
    patch, must include test cases for the regression test and
    documentation.  A patch should not be checked in until the tests
    and documentation are ready.

    If you fix a bug, you should write a test case that would have
    caught the bug.

    If you commit a patch from the SF Patch Manager or fix a bug from
    the Jitterbug database, be sure to reference the patch/bug number
    in the CVS log message.  Also be sure to change the status in the
    patch manager or bug database (if you have access to the bug
    database).

    It is not acceptable for any checked in code to cause the
    regression test to fail.  If a checkin causes a failure, it must
    be fixed within 24 hours or it will be backed out.

    All contributed C code must be ANSI C.  If possible check it with
    two different compilers, e.g. gcc and MSVC.

    All contributed Python code must follow Guido's Python style
    guide.  http://www.python.org/doc/essays/styleguide.html

    It is understood that any code contributed will be released under
    an Open Source license.  Do not contribute code if it can't be
    released this way.

Failing test cases need to get fixed

    We need to resolve errors in the regression test suite quickly.
    Changes should not be committed to the CVS tree unless the
    regression test runs cleanly with the changes applied.  If it
    fails, there may be bugs lurking in the code.  (There may be bugs
    anyway, but that's another matter.)  If the test cases are known
    to fail, they serve no useful purpose.

    The current test suite runs correctly on my Linux box (July 26).
    Heard reports that test_fork1 fails on some Linux boxes and that
    test_winreg and test_winreg32 fail on Windows.

Open items -- should be done/fixed

    Decoding errors when comparing strings.  There is a dictionary bug
    that prevents objects from being accessible when an exception is
    raised during hashing or comparison.


Accepted and completed


Accepted and in progress

    * SyntaxError enhancements - Fredrik Lundh
      http://www.python.org/pipermail/python-dev/2000-July/012981.html

    * interface to poll system call - Andrew Kuchling
      An OO interface to the poll system call will be added to the
      select module.

    * Compression of Unicode database - Fredrik Lundh
      http://hem.passagen.se/eff/bot.htm#456806

    * SRE - Fredrik Lundh
      The test suite still fails on test_re.

    * PyErr_SafeFormat / snprintf - owner???
      Use snprintf to avoid buffer overflows.  Need configure hackery
      to discovery if it is available on the current platform and a
      default implementation if it is not.
      http://www.python.org/pipermail/python-dev/2000-April/010051.html

    * Support for opcode arguments > 2**16 - Charles Waldman
      Source files longer than 32K and sequences with more than 32K
      elements both fail because opcode arguments are limited to
      16-bit values.

    * Range literals - Thomas Wouters
      Make range(1, 10, 2) == [1:10:2]


Open: proposed but not accepted or declined

    * List comprehensions - Tim Peters?
      Need a coherent proposal.  Lots of confusing discussion going
      on.

    * Eliminated SET_LINENO opcode - Vladimir Marangozov
      Small optimization achieved by using the code object's lnotab
      instead of the SET_LINENO instruction.  Uses code rewriting
      technique (that Guido's frowns on) to support debugger, which
      uses SET_LINENO.

      http://starship.python.net/~vlad/lineno/
      for (working at the time) patches

      Discussions on python-dev:

      - http://www.python.org/pipermail/python-dev/2000-April/subject.html
        Subject: "Why do we need Traceback Objects?"

      - http://www.python.org/pipermail/python-dev/1999-August/002252.html


Declined


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