iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Another status update. Added new sections "Completed" and "Unlikely".

This commit is contained in:
Guido van Rossum 2002-08-15 16:50:55 +00:00
parent c055edb47d
commit b061a91037
1 changed files with 105 additions and 96 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

201
pep-0283.txt
View File

@ -32,60 +32,81 @@ Release Manager
Barry Warsaw. (Didn't have his finger on his nose in time. :)
Planned features for 2.3
Completed 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
This project has been dormant too long. Somebody wake it up!
http://www.python.org/sf/492105
- PEP 282 A Logging System Mick
Vinay Sajip's implementation is close to completion IMO. I
expect that his code will be incorporated in the near future.
http://www.python.org/sf/578494
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).
- PEP 218 Adding a Built-In Set Object Type
- 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
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
- PEP 218 Adding a Built-In Set Object Type Wilson
I think it would be good to revive this in some form, using a
module rather than a built-in type. Alex Martelli has
contributed a new version: http://www.python.org/sf/580995
- A new command line option parser. Greg Ward's Optik
(http://optik.sf.net) would fit the bill fine; there's only some
(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/
@ -94,16 +115,9 @@ Planned features for 2.3
http://mail.python.org/pipermail/python-dev/2002-May/024346.html
Unfortunately there hasn't been much progress on this.
- Extended slice notation for all built-in sequences. Completed:
patch by Michael Hudson is now all checked in.
- 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
and tuple objects.)
- 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
@ -111,53 +125,14 @@ Planned features for 2.3
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.
- 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.
- Timeout sockets. Completed.
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
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%.
http://www.python.org/sf/587993 awaiting review.
- 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.)
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
@ -169,11 +144,6 @@ Planned features for 2.3
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).
@ -192,7 +162,7 @@ Planned features for 2.3
- Remove use of deprecated features in the core.
- Doc deprecated features appropriately
- Document deprecated features appropriately.
- Move deprecated features under Py_DEPRECATED (or whatever is decided)
@ -202,6 +172,45 @@ Planned features for 2.3
- 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/
- PEP 269 Pgen Module for Python Riehl
Based on Jonathan Riehl's latest posts in the parser-sig, e.g.
http://mail.python.org/pipermail/parser-sig/2002-August/000012.html
I consider this project dead.
- 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.
- 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.
- 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).
Copyright
This document has been placed in the public domain.