245 lines
9.0 KiB
Plaintext
245 lines
9.0 KiB
Plaintext
PEP: 283
|
||
Title: Python 2.3 Release Schedule
|
||
Version: $Revision$
|
||
Author: Guido van Rossum
|
||
Status: Incomplete
|
||
Type: Informational
|
||
Created: 27-Feb-2002
|
||
Python-Version: 2.3
|
||
Post-History: 27-Feb-2002
|
||
|
||
Abstract
|
||
|
||
This document describes the development and release schedule for
|
||
Python 2.3. The schedule primarily concerns itself with PEP-sized
|
||
items. Small features may be added until the first beta release.
|
||
Bugs may be fixed until the final release.
|
||
|
||
There is currently no defined schedule. We hope to do the final
|
||
release before the end of 2002, but if important projects below
|
||
are delayed, even that may be delayed.
|
||
|
||
There will be at least two alpha releases, two beta releases, and
|
||
one release candidate. Alpha and beta releases will be spaced at
|
||
least 4 weeks apart (except if an emergency release must be made
|
||
to correct a blunder in the previous release; then the blunder
|
||
release does not count). Release candidates will be spaced at
|
||
least one week apart (excepting again blunder corrections).
|
||
|
||
|
||
Release Manager
|
||
|
||
Barry Warsaw. (Didn't have his finger on his nose in time. :)
|
||
|
||
|
||
Open issues
|
||
|
||
There are some issues that may need more work and/or thought
|
||
before the final release (and preferably before the first beta
|
||
release). For example:
|
||
|
||
- Set API issues; is the sets module perfect?
|
||
|
||
- 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?)
|
||
|
||
- Fredrik Lundh's basetime proposal:
|
||
http://effbot.org/ideas/time-type.htm
|
||
|
||
- New widgets for Tkinter???
|
||
|
||
- Tk 8.4 update.
|
||
|
||
|
||
Completed features for 2.3
|
||
|
||
This list is not complete; e.g. missing are bool, PyMalloc, and
|
||
universal newlines, which were in before this PEP appeared.
|
||
|
||
- PEP 263 Defining Python Source Code Encodings
|
||
|
||
Implemented (at least phase 1, which is all that's planned for
|
||
2.3).
|
||
|
||
- Extended slice notation for all built-in sequences. The patch
|
||
by Michael Hudson is now all checked in.
|
||
|
||
- Speed up list iterations by filling tp_iter and other tweaks.
|
||
See http://www.python.org/sf/560736; also done for xrange and
|
||
tuples.
|
||
|
||
- Timeout sockets. http://www.python.org/sf/555085
|
||
|
||
- Stage B0 of the int/long integration (PEP 237). This means
|
||
issuing a FutureWarning about situations where hex or oct
|
||
conversions or left shifts returns a different value for an int
|
||
than for a long with the same value. The semantics do *not*
|
||
change in Python 2.3; that will happen in Python 2.4.
|
||
|
||
- Nuke SET_LINENO from all code objects (providing a different way
|
||
to set debugger breakpoints). This can boost pystone by >5%.
|
||
http://www.python.org/sf/587993, now checked in. (Unfortunately
|
||
the pystone boost didn't happen. What happened?)
|
||
|
||
- Write a pymemcompat.h that people can bundle with their
|
||
extensions and then use the 2.3 memory interface with all
|
||
Pythons in the range 1.5.2 to 2.3. (Michael Hudson checked in
|
||
Misc/pymemcompat.h.)
|
||
|
||
- Add a new concept, "pending deprecation", with associated
|
||
warning PendingDeprecationWarning. This warning is normally
|
||
suppressed, but can be enabled by a suitable -W option. (This
|
||
has been added, but nothing uses it yet.)
|
||
|
||
- Warn when an extension type's tp_compare returns anything except
|
||
-1, 0 or 1. http://www.python.org/sf/472523
|
||
|
||
- Warn for assignment to None (in various forms).
|
||
|
||
- PEP 218 Adding a Built-In Set Object Type Wilson
|
||
|
||
Alex Martelli contributed a new version of Greg Wilson's
|
||
prototype, and I've reworked that quite a bit. It's in the
|
||
standard library now as the module "sets", although some details
|
||
may still change until the first beta release. (There are no
|
||
plans to make this a built-in type, for now.)
|
||
|
||
|
||
Planned features for 2.3
|
||
|
||
Here are a few PEPs and other ideas under consideration, with
|
||
comments in "parade of the PEPs" style. Not all of these will be
|
||
part of the final 2.3 release; we'll update the list as decisions
|
||
crystallize.
|
||
|
||
This is pretty much an unordered laundry list. Please send
|
||
feedback to python-dev@python.org; I hope to maintain this for the
|
||
life of the 2.3 development process.
|
||
|
||
- PEP 273 Import Modules from Zip Archives Ahlstrom
|
||
|
||
There's hope for an updated patch at
|
||
http://www.python.org/sf/492105
|
||
|
||
- PEP 282 A Logging System Mick
|
||
|
||
Vinay Sajip's implementation is close to completion, but could
|
||
stand a restructuring (some of the classes don't belong in the
|
||
core module; maybe the whole thing should become a package).
|
||
http://www.python.org/sf/578494
|
||
|
||
- A new command line option parser. Greg Ward's Optik
|
||
(http://optik.sf.net) fits the bill fine; there's only some
|
||
question about whether it should be given a less "cutesy" name.
|
||
See also http://www.python.org/sigs/getopt-sig/
|
||
|
||
- 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
|
||
Unfortunately there hasn't been much progress on this.
|
||
|
||
- An iterator tools module featuring goodies from SML and Haskell?
|
||
http://mail.python.org/pipermail/python-dev/2002-May/024418.html
|
||
|
||
- 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
|
||
No progress; the last time this was brought up only Marc-Andre
|
||
Lemburg said he had a use for it. I need to find out exactly
|
||
what that need is and how much of the buffer object we can retire.
|
||
|
||
- PEP 262 Database of Installed Python Packages Kuchling
|
||
|
||
Andrew is still hopeful that he'll implement this.
|
||
|
||
- 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.
|
||
|
||
- A standard datetime type. An implementation effort is under way:
|
||
http://www.zope.org/Members/fdrake/DateTimeWiki/FrontPage
|
||
Effbot and MAL have a proposal for a basic interface that all
|
||
datetime types should implement, but there are some problems with
|
||
UTC. A decision needs to be made.
|
||
|
||
- 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
|
||
|
||
- 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).
|
||
|
||
- PEP 269 Pgen Module for Python Riehl
|
||
|
||
Jon Riehl is going to attempt an implementation by mid-September.
|
||
|
||
- Documentation: complete the distribution and installation
|
||
manuals.
|
||
|
||
- Documentation: complete the documentation for new-style
|
||
classes.
|
||
|
||
- Look over the Demos/ directory and update where required.
|
||
|
||
- New tests.
|
||
|
||
- Fix doc bugs on SF.
|
||
|
||
- Remove use of deprecated features in the core.
|
||
|
||
- Document deprecated features appropriately.
|
||
|
||
- Move deprecated features under Py_DEPRECATED (or whatever is decided)
|
||
|
||
- 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.
|
||
|
||
|
||
Features unlikely to make it into Python 2.3
|
||
|
||
- 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:
|