213 lines
8.3 KiB
Plaintext
213 lines
8.3 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 release at
|
||
least the first alpha before OSCON 2002, and the final release
|
||
before the end of 2002, but if important projects below are
|
||
delayed, the release 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. :)
|
||
|
||
|
||
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. (There's also a bunch of things already implemented,
|
||
like bool, PyMalloc, and universal newlines.)
|
||
|
||
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 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/
|
||
|
||
- PEP 269 Pgen Module for Python Riehl
|
||
|
||
I haven't heard from Jon Riehl, so I consider dropping this idea.
|
||
|
||
- PEP 273 Import Modules from Zip Archives Ahlstrom
|
||
|
||
I think this is close -- maybe it's already checked in and I
|
||
don't know about it!
|
||
|
||
- PEP 282 A Logging System Mick
|
||
|
||
Vinay Sajip has been making steady progress on an
|
||
implementation, and despite a recent near-flamewar (which I
|
||
haven't followed) I expect that his code will be incorporated in
|
||
the near future.
|
||
|
||
- PEP 263 Defining Python Source Code Encodings
|
||
|
||
I'm all for this plan. I haven't reviewed the implementation.
|
||
|
||
- PEP 218 Adding a Built-In Set Object Type
|
||
|
||
I think it would be good to revive this in some form, using a
|
||
module rather than a built-in type.
|
||
|
||
- A new command line option parser. Greg Ward's Optik
|
||
(http://optik.sf.net) would fit 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
|
||
|
||
- Extended slice notation for all built-in sequences. A patch by
|
||
Michael Hudson has solved this, mostly; there's an open issue
|
||
about slice assignments where the source has a different length
|
||
than the destination, as in L[:5:] = range(10).
|
||
|
||
- An iterator tools module featuring goodies from SML and Haskell?
|
||
http://mail.python.org/pipermail/python-dev/2002-May/024418.html
|
||
|
||
- Speed up list iterations by filling tp_iter and other tweaks?
|
||
http://www.python.org/sf/560736 (This is done; also for xrange.)
|
||
|
||
- 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
|
||
|
||
- Lazily tracking tuples?
|
||
http://mail.python.org/pipermail/python-dev/2002-May/023926.html
|
||
http://www.python.org/sf/558745
|
||
|
||
- Timeoutsocket. Work in progress.
|
||
http://mail.python.org/pipermail/python-dev/2002-May/024077.html
|
||
http://www.python.org/sf/555085 (Most of this is done, but we
|
||
still need to add a global timeout option.)
|
||
|
||
- Making None a keyword. Can't be done right away, but a warning
|
||
would be a first step.
|
||
http://mail.python.org/pipermail/python-dev/2002-April/023600.html
|
||
Ditto for 'as', which has been a pseudo-keyword long enough.
|
||
|
||
- Stage 2 of the int/long integration (PEP 237). This mostly
|
||
means warning about situations where hex, oct or shift of an int
|
||
returns a different value than for the same value as a long. I
|
||
propose *not* to change the semantics this time; that will
|
||
happen in the next release, still with a warning. (I think the
|
||
PEP misses this step, but it's necessary -- we can't just change
|
||
the semantics silently without warning first.) Does this need a
|
||
__future__ statement???
|
||
|
||
- Nuke SET_LINENO from all code objects (providing a different way
|
||
to set debugger breakpoints). This can boost pystone by >5%.
|
||
(Tim Peters.)
|
||
|
||
- 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 has done
|
||
this; it's in Misc/pymemcompat.h.)
|
||
|
||
- 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 is working on an implementation (he's planning a demo
|
||
for OSCON 2002). What else is needed?
|
||
|
||
- 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).
|
||
|
||
- Warn when an extension type's tp_compare returns anything except
|
||
-1, 0 or 1. http://www.python.org/sf/472523 (This is done.)
|
||
|
||
- 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
|
||
|
||
- 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 now, but nothing uses it yet.)
|
||
|
||
- 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).
|
||
|
||
- 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.
|
||
|
||
- Doc 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.
|
||
|
||
|
||
Copyright
|
||
|
||
This document has been placed in the public domain.
|
||
|
||
|
||
|
||
Local Variables:
|
||
mode: indented-text
|
||
indent-tabs-mode: nil
|
||
End:
|