python-peps/pep-0200.txt

245 lines
8.5 KiB
Plaintext
Raw Normal View History

PEP: 200
Title: Python 2.0 Release Schedule
Version: $Revision$
Owner: Jeremy Hylton <jeremy@beopen.com>
Python-Version: 2.0
Status: Incomplete
2000-07-21 14:29:05 -04:00
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.
2000-08-15 01:58:29 -04:00
Tentative Release Schedule
2000-08-15 01:58:29 -04:00
14-Aug-2000: All 2.0 PEPs finished / feature freeze
28-Aug-2000: 2.0 beta 1
29-Sep-2000: 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
2000-08-15 01:58:29 -04:00
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.
2000-07-21 14:29:05 -04:00
2000-08-15 01:58:29 -04:00
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.
2000-08-15 01:58:29 -04:00
[what are the "R" and "B" columns supposed to mean? - tim]
test case platform R B date reported
--------- -------- - - -------------
test_longexp Win98+? ? ? 15-Aug-2000
[fails in release build,
passes in release build under verbose mode but doesn't
look like it should pass,
passes in debug build,
passes in debug build under verbose mode and looks like
it should pass
]
2000-08-15 01:58:29 -04:00
test_winreg2 Win32 X X 26-Jul-2000
[still fails 15-Aug-2000 for me, on Win98 - tim
test test_winreg2 failed -- Writing: 'Test Failed: testHives',
expected: 'HKEY_PERFORMANCE_DATA\012'
]
test_popen2 Win32 X X 26-Jul-2000
[still fails 15-Aug-2000 for me, on Win98 - tim
test test_popen2 crashed -- exceptions.AssertionError :
The problem is that the test uses "cat", but there is
no such thing under Windows (unless you install it).
So it's the test that's broken here, not (necessarily)
the code.
2000-08-15 01:58:29 -04:00
]
test_fork1 Linux X 26-Jul-2000 just SMP?
[no clue; there are probably two bugs here]
2000-08-15 01:58:29 -04:00
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!
test case platform R B date reported
--------- -------- - - -------------
2000-08-15 01:58:29 -04:00
test_winreg Win32 X X 26-Jul-2000
[works 15-Aug-2000 for me, on Win98 - tim]
test_mmap Win32 X X 26-Jul-2000
[believe that was fixed by Mark H.]
[works 15-Aug-2000 for me, on Win98 - tim]
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
2000-08-15 01:58:29 -04:00
* Lockstep iteration ("zip" function) - Barry Warsaw
* SRE - Fredrik Lundh
[at least I *think* it's done, as of 15-Aug-2000 - tim]
* Fix xrange printing behavior - Fred Drake
[although I'm not sure what this one was talking about - tim]
2000-07-21 14:29:05 -04:00
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
* 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]
2000-08-15 01:58:29 -04:00
* List comprehensions - Skip Montanaro (Tim Peters for PEP)
Need a coherent proposal. Lots of confusing discussion going
on.
[note: it's not confusing to Guido <wink> - tim]
2000-07-21 14:29:05 -04:00
* Augmented assignment - Thomas Wouters
Add += and family, plus Python and C hooks, and API functions.
2000-08-15 01:58:29 -04:00
Open: proposed but not accepted or declined
* Tim O'Malley's cookie module -- but need different license
* test harness for C code - Trent Mick
* 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
* "import as" - Thomas Wouters
Extend the 'import' and 'from ... import' mechanism to enable
importing a symbol as another name. (Without adding a new keyword.)
* Extended slicing on lists - Michael Hudson
Make lists (and other builtin types) handle extended slices.
* Merge __getitem__ and __getslice__ - Thomas Wouters
Move __getslice__ functionality into __getitem__, using slice objects,
for normal slices as well as for extended ones. First step: use
getitem if there is no getslice.
* 'indexing-for' - Thomas Wouters
Special syntax to give Python code access to the loop-counter in 'for'
loops. (Without adding a new keyword.)
* Integrated gettext module - Barry Warsaw
wrapper around standard internationalization libraries
* Extended print statement - Barry Warsaw
PEP 214
http://python.sourceforge.net/peps/pep-0214.html
SF Patch #100970
http://sourceforge.net/patch/?func=detailpatch&patch_id=100970&group_id=5470
2000-07-21 14:29:05 -04:00
Declined
Local Variables:
mode: indented-text
indent-tabs-mode: nil
End: