[Python-checkins] python/nondist/peps pep-0283.txt,1.4,1.5
gvanrossum@users.sourceforge.net
gvanrossum@users.sourceforge.net
Tue, 28 May 2002 08:54:47 -0700
Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv8965
Modified Files:
pep-0283.txt
Log Message:
Total rewrite. Claimed authorship. (Will update PEP 0 too.)
Index: pep-0283.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0283.txt,v
retrieving revision 1.4
retrieving revision 1.5
diff -C2 -d -r1.4 -r1.5
*** pep-0283.txt 25 May 2002 00:19:11 -0000 1.4
--- pep-0283.txt 28 May 2002 15:54:45 -0000 1.5
***************
*** 2,6 ****
Title: Python 2.3 Release Schedule
Version: $Revision$
! Author: jeremy@zope.com (Jeremy Hylton)
Status: Incomplete
Type: Informational
--- 2,6 ----
Title: Python 2.3 Release Schedule
Version: $Revision$
! Author: Guido van Rossum
Status: Incomplete
Type: Informational
***************
*** 11,55 ****
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.
!
! 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.
!
! This schedule will change! See the discussion started here:
! http://mail.python.org/pipermail/python-dev/2002-May/024395.html
! 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
Planned features for 2.3
! TBD
! 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.
- 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
--- 11,179 ----
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.
!
! - 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.
Copyright