161 lines
5.4 KiB
Plaintext
161 lines
5.4 KiB
Plaintext
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:
|