Convert PEP 200 to reST. (#49)
This commit is contained in:
Matthias Bussonnier
Berker Peksag
parent
8f12586fb2
commit
99722904ba
302
pep-0200.txt
302
pep-0200.txt
|
|
@ -5,103 +5,113 @@ Last-Modified: $Date$
|
|||
Author: Jeremy Hylton <jeremy@alum.mit.edu>
|
||||
Status: Final
|
||||
Type: Informational
|
||||
Content-Type: text/x-rst
|
||||
Created:
|
||||
Python-Version: 2.0
|
||||
Post-History:
|
||||
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
Release Schedule
|
||||
[revised 5 Oct 2000]
|
||||
================
|
||||
|
||||
26-Sep-2000: 2.0 beta 2
|
||||
9-Oct-2000: 2.0 release candidate 1 (2.0c1)
|
||||
16-Oct-2000: 2.0 final
|
||||
[revised 5 Oct 2000]
|
||||
|
||||
|
||||
* 26-Sep-2000: 2.0 beta 2
|
||||
* 9-Oct-2000: 2.0 release candidate 1 (2.0c1)
|
||||
* 16-Oct-2000: 2.0 final
|
||||
|
||||
Previous milestones
|
||||
14-Aug-2000: All 2.0 PEPs finished / feature freeze
|
||||
5-Sep-2000: 2.0 beta 1
|
||||
===================
|
||||
|
||||
* 14-Aug-2000: All 2.0 PEPs finished / feature freeze
|
||||
* 5-Sep-2000: 2.0 beta 1
|
||||
|
||||
What is release candidate 1?
|
||||
============================
|
||||
|
||||
We believe that release candidate 1 will fix all known bugs that
|
||||
we intend to fix for the 2.0 final release. This release should
|
||||
be a bit more stable than the previous betas. We would like to
|
||||
see even more widespread testing before the final release, so we
|
||||
are producing this release candidate. The final release will be
|
||||
exactly the same unless any show-stopping (or brown bag) bugs are
|
||||
found by testers of the release candidate.
|
||||
We believe that release candidate 1 will fix all known bugs that we
|
||||
intend to fix for the 2.0 final release. This release should be a bit
|
||||
more stable than the previous betas. We would like to see even more
|
||||
widespread testing before the final release, so we are producing this
|
||||
release candidate. The final release will be exactly the same unless
|
||||
any show-stopping (or brown bag) bugs are found by testers of the
|
||||
release candidate.
|
||||
|
||||
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:
|
||||
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.
|
||||
* 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.
|
||||
* 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 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.
|
||||
* 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.
|
||||
* 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 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.
|
||||
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 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).
|
||||
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.
|
||||
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 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
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
|
||||
::
|
||||
|
||||
test case platform date reported
|
||||
--------- -------- -------------
|
||||
|
|
@ -115,39 +125,45 @@ Failing test cases need to get fixed
|
|||
]
|
||||
|
||||
Open items -- Need to be resolved before 2.0 final release
|
||||
==========================================================
|
||||
|
||||
Decide whether cycle-gc should be enabled by default.
|
||||
Decide whether cycle-gc should be enabled by default.
|
||||
|
||||
Resolve compatibility issues between core xml package and the
|
||||
XML-SIG XML package.
|
||||
Resolve compatibility issues between core xml package and the XML-SIG
|
||||
XML package.
|
||||
|
||||
Update Tools/compiler so that it is compatible with list
|
||||
comprehensions, import as, and any other new language features.
|
||||
Update Tools/compiler so that it is compatible with list
|
||||
comprehensions, import as, and any other new language features.
|
||||
|
||||
Improve code coverage of test suite.
|
||||
Improve code coverage of test suite.
|
||||
|
||||
Finish writing the PEPs for the features that went out with
|
||||
2.0b1(! sad, but realistic -- we'll get better with practice).
|
||||
Finish writing the PEPs for the features that went out with 2.0b1(!
|
||||
sad, but realistic -- we'll get better with practice).
|
||||
|
||||
Major effort to whittle the bug database down to size. I've (tim)
|
||||
seen this before: if you can keep all the open bugs fitting on one
|
||||
screen, people will generally keep it that way. But let it
|
||||
slobber over a screen for a month, & it just goes to hell (no
|
||||
"visible progress" indeed!).
|
||||
Major effort to whittle the bug database down to size. I've (tim)
|
||||
seen this before: if you can keep all the open bugs fitting on one
|
||||
screen, people will generally keep it that way. But let it slobber
|
||||
over a screen for a month, & it just goes to hell (no "visible
|
||||
progress" indeed!).
|
||||
|
||||
Accepted and in progress
|
||||
========================
|
||||
|
||||
* Currently none left. [4-Sep-2000 guido]
|
||||
* Currently none left. [4-Sep-2000 guido]
|
||||
|
||||
Open: proposed but not accepted or rejected
|
||||
===========================================
|
||||
|
||||
* There are a number of open patches again. We need to clear
|
||||
these out soon.
|
||||
* There are a number of open patches again. We need to clear these
|
||||
out soon.
|
||||
|
||||
Previously failing test cases
|
||||
=============================
|
||||
|
||||
If you find a test bouncing between this section and the previous one,
|
||||
the code it's testing is in trouble!
|
||||
If you find a test bouncing between this section and the previous one,
|
||||
the code it's testing is in trouble!
|
||||
|
||||
::
|
||||
|
||||
test case platform date reported
|
||||
--------- -------- -------------
|
||||
|
|
@ -233,8 +249,10 @@ Previously failing test cases
|
|||
expected: 'HKEY_PERFORMANCE_DATA\012'
|
||||
]
|
||||
|
||||
|
||||
Open items -- completed/fixed
|
||||
=============================
|
||||
|
||||
::
|
||||
|
||||
[4-Sep-2000 guido: Fredrik finished this on 1-Sep]
|
||||
* PyErr_Format - Fredrik Lundh
|
||||
|
|
@ -277,97 +295,93 @@ Open items -- completed/fixed
|
|||
whole machine. Was caused by Norton Antivirus 2000 (6.10.20) on
|
||||
Windows 9x. Resolution: disable virus protection.
|
||||
|
||||
|
||||
Accepted and completed
|
||||
======================
|
||||
|
||||
* Change meaning of \x escapes - PEP 223 - Fredrik Lundh
|
||||
* Change meaning of \x escapes - PEP 223 - Fredrik Lundh
|
||||
|
||||
* Add \U1234678 escapes in u"" strings - Fredrik Lundh
|
||||
* Add \U1234678 escapes in u"" strings - Fredrik Lundh
|
||||
|
||||
* Support for opcode arguments > 2**16 - Charles Waldman
|
||||
SF Patch 100893
|
||||
* Support for opcode arguments > ``2**16`` - Charles Waldman SF Patch
|
||||
100893
|
||||
|
||||
* "import as" - Thomas Wouters
|
||||
Extend the 'import' and 'from ... import' mechanism to enable
|
||||
importing a symbol as another name. (Without adding a new keyword.)
|
||||
* "import as" - Thomas Wouters Extend the 'import' and 'from ...
|
||||
import' mechanism to enable importing a symbol as another name.
|
||||
(Without adding a new keyword.)
|
||||
|
||||
* List comprehensions - Skip Montanaro
|
||||
Tim Peters still needs to do PEP.
|
||||
* List comprehensions - Skip Montanaro Tim Peters still needs to do
|
||||
PEP.
|
||||
|
||||
* Restore old os.path.commonprefix behavior
|
||||
Do we have test cases that work on all platforms?
|
||||
* Restore old os.path.commonprefix behavior Do we have test cases that
|
||||
work on all platforms?
|
||||
|
||||
* Tim O'Malley's cookie module with good license
|
||||
* Tim O'Malley's cookie module with good license
|
||||
|
||||
* Lockstep iteration ("zip" function) - Barry Warsaw
|
||||
* Lockstep iteration ("zip" function) - Barry Warsaw
|
||||
|
||||
* SRE - Fredrik Lundh
|
||||
[at least I *think* it's done, as of 15-Aug-2000 - tim]
|
||||
* SRE - Fredrik Lundh [at least I **think** it's done, as of
|
||||
15-Aug-2000 - tim]
|
||||
|
||||
* Fix xrange printing behavior - Fred Drake
|
||||
Remove the tp_print handler for the xrange type; it produced a
|
||||
list display instead of 'xrange(...)'. The new code produces a
|
||||
minimal call to xrange(), enclosed in (... * N) when N != 1.
|
||||
This makes the repr() more human readable while making it do
|
||||
what reprs are advertised as doing. It also makes the xrange
|
||||
objects obvious when working in the interactive interpreter.
|
||||
* Fix xrange printing behavior - Fred Drake Remove the tp_print
|
||||
handler for the xrange type; it produced a list display instead of
|
||||
'xrange(...)'. The new code produces a minimal call to xrange(),
|
||||
enclosed in (``... * N``) when N != 1. This makes the repr() more
|
||||
human readable while making it do what reprs are advertised as
|
||||
doing. It also makes the xrange objects obvious when working in the
|
||||
interactive interpreter.
|
||||
|
||||
* Extended print statement - Barry Warsaw
|
||||
PEP 214
|
||||
http://www.python.org/dev/peps/pep-0214/
|
||||
SF Patch #100970
|
||||
http://sourceforge.net/patch/?func=detailpatch&patch_id=100970&group_id=5470
|
||||
* Extended print statement - Barry Warsaw PEP 214
|
||||
http://www.python.org/dev/peps/pep-0214/ SF Patch #100970
|
||||
http://sourceforge.net/patch/?func=detailpatch&patch_id=100970&group_id=5470
|
||||
|
||||
* interface to poll system call - Andrew Kuchling
|
||||
SF Patch 100852
|
||||
* interface to poll system call - Andrew Kuchling SF Patch 100852
|
||||
|
||||
* Augmented assignment - Thomas Wouters
|
||||
Add += and family, plus Python and C hooks, and API functions.
|
||||
* Augmented assignment - Thomas Wouters Add += and family, plus Python
|
||||
and C hooks, and API functions.
|
||||
|
||||
* gettext.py module - Barry Warsaw
|
||||
* gettext.py module - Barry Warsaw
|
||||
|
||||
|
||||
Postponed
|
||||
=========
|
||||
|
||||
* Extended slicing on lists - Michael Hudson
|
||||
Make lists (and other builtin types) handle extended slices.
|
||||
* Extended slicing on lists - Michael Hudson Make lists (and other
|
||||
builtin types) handle extended slices.
|
||||
|
||||
* Compression of Unicode database - Fredrik Lundh
|
||||
SF Patch 100899
|
||||
At least for 2.0b1. May be included in 2.0 as a bug fix.
|
||||
* Compression of Unicode database - Fredrik Lundh SF Patch 100899 At
|
||||
least for 2.0b1. May be included in 2.0 as a bug fix.
|
||||
|
||||
* Range literals - Thomas Wouters
|
||||
SF Patch 100902
|
||||
We ended up having a lot of doubt about the proposal.
|
||||
* Range literals - Thomas Wouters SF Patch 100902 We ended up having a
|
||||
lot of doubt about the proposal.
|
||||
|
||||
* 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.
|
||||
* 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
|
||||
http://starship.python.net/~vlad/lineno/ for (working at the time)
|
||||
patches
|
||||
|
||||
Discussions on python-dev:
|
||||
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/2000-April/subject.html
|
||||
Subject: "Why do we need Traceback Objects?"
|
||||
|
||||
- http://www.python.org/pipermail/python-dev/1999-August/002252.html
|
||||
|
||||
- http://www.python.org/pipermail/python-dev/1999-August/002252.html
|
||||
|
||||
* test harness for C code - Trent Mick
|
||||
* test harness for C code - Trent Mick
|
||||
|
||||
|
||||
Rejected
|
||||
========
|
||||
|
||||
* 'indexing-for' - Thomas Wouters
|
||||
Special syntax to give Python code access to the loop-counter in 'for'
|
||||
loops. (Without adding a new keyword.)
|
||||
|
||||
* 'indexing-for' - Thomas Wouters Special syntax to give Python code
|
||||
access to the loop-counter in 'for' loops. (Without adding a new
|
||||
keyword.)
|
||||
|
||||
|
||||
Local Variables:
|
||||
mode: indented-text
|
||||
indent-tabs-mode: nil
|
||||
End:
|
||||
..
|
||||
Local Variables:
|
||||
mode: indented-text
|
||||
indent-tabs-mode: nil
|
||||
End:
|
||||
|
|
|
|||
Loading…
Reference in New Issue