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