Total rewrite. Claimed authorship. (Will update PEP 0 too.)

This commit is contained in:
Guido van Rossum 2002-05-28 15:54:45 +00:00
parent 8400ef771c
commit 00d8d1685e
1 changed files with 155 additions and 31 deletions

View File

@ -1,7 +1,7 @@
PEP: 283
Title: Python 2.3 Release Schedule
Version: $Revision$
Author: jeremy@zope.com (Jeremy Hylton)
Author: Guido van Rossum
Status: Incomplete
Type: Informational
Created: 27-Feb-2002
@ -10,47 +10,171 @@ Post-History: 27-Feb-2002
Abstract
This document describes the post-Python 2.2 development and
release schedule. The schedule primarily concerns itself with
PEP-sized items. Small bug fixes and changes will occur up until
the first beta release.
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.
NOTE: the schedule below and the list of features under
consideration are all subject to change! If the energy in the
community changes or the feedback on a PEP is particularly
positive or negative, this may affect decisions.
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.
This schedule will change! See the discussion started here:
http://mail.python.org/pipermail/python-dev/2002-May/024395.html
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 Schedule
Tentative future release dates.
30-Aug-2002: 2.3 (final release)
26-Aug-2002: 2.3c1 (release candidate)
14-Aug-2002: 2.3b2
17-Jul-2002: 2.3b1
19-Jun-2002: 2.3a2
22-May-2002: 2.3a1
Release Manager
TBD
Barry Warsaw. (Didn't have his finger on his nose in time. :)
Planned features for 2.3
TBD
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.)
Here are a few PEPs that I know to be under consideration. If a
PEP isn't on this list, it's because I'm not a confident channeler.
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.
- 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. Raymond
Hettinger is working on this.
- 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
- Fix the buffer object???
http://mail.python.org/pipermail/python-dev/2002-May/023896.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
- 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
- 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.)
- 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
- 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.
- PEP 272 API for Block Encryption Algorithms Kuchling
Andrew wants to finish this. I've heard one person (who shall
remain nameless) comment that there's no need for such an API.
- 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
- 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.
PEP 266 Optimizing Global Variable/Attribute Access Montanaro
PEP 267 Optimized Access to Module Namespaces Hylton
PEP 269 Pgen Module for Python Riehl
PEP 273 Import Modules from Zip Archives Ahlstrom
PEP 280 Optimizing access to globals van Rossum
PEP 282 A Logging System Mick
Copyright