Total rewrite. Claimed authorship. (Will update PEP 0 too.)
This commit is contained in:
parent
8400ef771c
commit
00d8d1685e
186
pep-0283.txt
186
pep-0283.txt
|
@ -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
|
||||
|
||||
|
|
Loading…
Reference in New Issue