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. :) 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 This list is not complete; e.g. missing are bool, PyMalloc, and
comments in "parade of the PEPs" style. Not all of these will be universal newlines, which were in before this PEP appeared.
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
- PEP 263 Defining Python Source Code Encodings - PEP 263 Defining Python Source Code Encodings
Implemented (at least phase 1, which is all that's planned for Implemented (at least phase 1, which is all that's planned for
2.3). 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 I think it would be good to revive this in some form, using a
module rather than a built-in type. Alex Martelli has module rather than a built-in type. Alex Martelli has
contributed a new version: http://www.python.org/sf/580995 contributed a new version: http://www.python.org/sf/580995
- A new command line option parser. Greg Ward's Optik - 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. question about whether it should be given a less "cutesy" name.
See also http://www.python.org/sigs/getopt-sig/ 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 http://mail.python.org/pipermail/python-dev/2002-May/024346.html
Unfortunately there hasn't been much progress on this. 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? - An iterator tools module featuring goodies from SML and Haskell?
http://mail.python.org/pipermail/python-dev/2002-May/024418.html 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. - Deprecate the buffer object.
http://mail.python.org/pipermail/python-dev/2002-July/026388.html http://mail.python.org/pipermail/python-dev/2002-July/026388.html
http://mail.python.org/pipermail/python-dev/2002-July/026408.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 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. 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 - PEP 262 Database of Installed Python Packages Kuchling
Andrew is still hopeful that he'll implement this. Andrew is still hopeful that he'll implement this.
- Add support for the long-awaited Python catalog. Kapil - Add support for the long-awaited Python catalog. Kapil
Thangavelu is working on an implementation (he's planning a demo Thangavelu has a Zope-based implementation that he demoed at
for OSCON 2002). What else is needed? OSCON 2002. Now all we need is a place to host it and a person
to champion it.
- 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: - A standard datetime type. An implementation effort is under way:
http://www.zope.org/Members/fdrake/DateTimeWiki/FrontPage 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: and act on it. For a start, see this message from Neil Norwitz:
http://mail.python.org/pipermail/python-dev/2002-April/023165.html 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 - Use pending deprecation for the types and string modules. This
requires providing alternatives for the parts that aren't requires providing alternatives for the parts that aren't
covered yet (e.g. string.whitespace and types.TracebackType). 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. - 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) - 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. - 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 Copyright
This document has been placed in the public domain. This document has been placed in the public domain.