The start of a Python 2.4 schedule PEP (I'm claiming the next free PEP
number)
This commit is contained in:
Barry Warsaw
parent
fe4914eda3
commit
1b569d92e5
|
|
@ -0,0 +1,184 @@
|
||||||
|
PEP: 320
|
||||||
|
Title: Python 2.4 Release Schedule
|
||||||
|
Version: $Revision$
|
||||||
|
Author: Barry Warsaw
|
||||||
|
Status: Incomplete
|
||||||
|
Type: Informational
|
||||||
|
Created: 29-Jul-2003
|
||||||
|
Python-Version: 2.4
|
||||||
|
Post-History:
|
||||||
|
|
||||||
|
Abstract
|
||||||
|
|
||||||
|
This document describes the development and release schedule for
|
||||||
|
Python 2.4. The schedule primarily concerns itself with PEP-sized
|
||||||
|
items. Small features may be added up to and including the first
|
||||||
|
beta release. Bugs may be fixed until the final release.
|
||||||
|
|
||||||
|
There will be at least two alpha releases, two beta releases, and
|
||||||
|
one release candidate. Other than that, no claims are made on
|
||||||
|
release plans, nor what will actually be in Python 2.4 at this
|
||||||
|
early date. There were 19 months between the Python 2.2 final and
|
||||||
|
Python 2.3 final releases. If that schedule holds true for Python
|
||||||
|
2.4, you can expect it some time around February 2005.
|
||||||
|
|
||||||
|
|
||||||
|
Release Manager
|
||||||
|
|
||||||
|
TBD
|
||||||
|
|
||||||
|
|
||||||
|
Completed features for 2.4
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
|
||||||
|
Planned features for 2.4
|
||||||
|
|
||||||
|
Too early for anything more to get done here.
|
||||||
|
|
||||||
|
|
||||||
|
Ongoing tasks
|
||||||
|
|
||||||
|
The following are ongoing TO-DO items which we should attempt to
|
||||||
|
work on without hoping for completion by any particular date.
|
||||||
|
|
||||||
|
- Documentation: complete the distribution and installation
|
||||||
|
manuals.
|
||||||
|
|
||||||
|
- Documentation: complete the documentation for new-style
|
||||||
|
classes.
|
||||||
|
|
||||||
|
- Look over the Demos/ directory and update where required (Andrew
|
||||||
|
Kuchling has done a lot of this)
|
||||||
|
|
||||||
|
- New tests.
|
||||||
|
|
||||||
|
- Fix doc bugs on SF.
|
||||||
|
|
||||||
|
- Remove use of deprecated features in the core.
|
||||||
|
|
||||||
|
- Document deprecated features appropriately.
|
||||||
|
|
||||||
|
- Mark deprecated C APIs with Py_DEPRECATED.
|
||||||
|
|
||||||
|
- 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.
|
||||||
|
|
||||||
|
|
||||||
|
Open issues
|
||||||
|
|
||||||
|
None at this time.
|
||||||
|
|
||||||
|
|
||||||
|
Carryover features from Python 2.3
|
||||||
|
|
||||||
|
- The import lock could use some redesign. (SF 683658.)
|
||||||
|
|
||||||
|
- Set API issues; is the sets module perfect?
|
||||||
|
|
||||||
|
I expect it's good enough to stop polishing it until we've had
|
||||||
|
more widespread user experience.
|
||||||
|
|
||||||
|
- A nicer API to open text files, replacing the ugly (in some
|
||||||
|
people's eyes) "U" mode flag. There's a proposal out there to
|
||||||
|
have a new built-in type textfile(filename, mode, encoding).
|
||||||
|
(Shouldn't it have a bufsize argument too?)
|
||||||
|
|
||||||
|
Ditto.
|
||||||
|
|
||||||
|
- New widgets for Tkinter???
|
||||||
|
|
||||||
|
Has anyone gotten the time for this? *Are* there any new
|
||||||
|
widgets in Tk 8.4? Note that we've got better Tix support
|
||||||
|
already (though not on Windows yet).
|
||||||
|
|
||||||
|
- Fredrik Lundh's basetime proposal:
|
||||||
|
http://effbot.org/ideas/time-type.htm
|
||||||
|
|
||||||
|
I believe this is dead now.
|
||||||
|
|
||||||
|
- PEP 304 (Controlling Generation of Bytecode Files by Montanaro)
|
||||||
|
seems to have lost steam.
|
||||||
|
|
||||||
|
- For a class defined inside another class, the __name__ should be
|
||||||
|
"outer.inner", and pickling should work. (SF 633930. I'm no
|
||||||
|
longer certain this is easy or even right.)
|
||||||
|
|
||||||
|
- reST is going to be used a lot in Zope3. Maybe it could become
|
||||||
|
a standard library module? (Since reST's author thinks it's too
|
||||||
|
instable, I'm inclined not to do this.)
|
||||||
|
|
||||||
|
- 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
|
||||||
|
There seems insufficient interest in moving this further in an
|
||||||
|
organized fashion, and it's not particularly important.
|
||||||
|
|
||||||
|
- 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
|
||||||
|
There hasn't been any progress on this, AFAICT.
|
||||||
|
|
||||||
|
- 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).
|
||||||
|
It seems we can't get consensus on this.
|
||||||
|
|
||||||
|
- Deprecate the buffer object.
|
||||||
|
http://mail.python.org/pipermail/python-dev/2002-July/026388.html
|
||||||
|
http://mail.python.org/pipermail/python-dev/2002-July/026408.html
|
||||||
|
It seems that this is never going to be resolved.
|
||||||
|
|
||||||
|
- PEP 269 Pgen Module for Python Riehl
|
||||||
|
|
||||||
|
(Some necessary changes are in; the pgen module itself needs to
|
||||||
|
mature more.)
|
||||||
|
|
||||||
|
- Add support for the long-awaited Python catalog. Kapil
|
||||||
|
Thangavelu has a Zope-based implementation that he demoed at
|
||||||
|
OSCON 2002. Now all we need is a place to host it and a person
|
||||||
|
to champion it. (Some changes to distutils to support this are
|
||||||
|
in, at least.)
|
||||||
|
|
||||||
|
- 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/
|
||||||
|
|
||||||
|
- Lazily tracking tuples?
|
||||||
|
http://mail.python.org/pipermail/python-dev/2002-May/023926.html
|
||||||
|
http://www.python.org/sf/558745
|
||||||
|
Not much enthusiasm I believe.
|
||||||
|
|
||||||
|
- 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).
|
||||||
|
|
||||||
|
- Make 'as' a keyword. It has been a pseudo-keyword long enough.
|
||||||
|
Too much effort to bother.
|
||||||
|
|
||||||
|
|
||||||
|
Copyright
|
||||||
|
|
||||||
|
This document has been placed in the public domain.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Local Variables:
|
||||||
|
mode: indented-text
|
||||||
|
indent-tabs-mode: nil
|
||||||
|
End:
|
||||||
Loading…
Reference in New Issue