[Python-checkins] r42266 - peps/trunk/pep-0000.txt peps/trunk/pep-0356.txt
neal.norwitz
python-checkins at python.org
Wed Feb 8 07:33:27 CET 2006
Author: neal.norwitz
Date: Wed Feb 8 07:33:27 2006
New Revision: 42266
Added:
peps/trunk/pep-0356.txt
Modified:
peps/trunk/pep-0000.txt
Log:
Very draft version of 2.5 release schedule.
Modified: peps/trunk/pep-0000.txt
==============================================================================
--- peps/trunk/pep-0000.txt (original)
+++ peps/trunk/pep-0000.txt Wed Feb 8 07:33:27 2006
@@ -60,6 +60,7 @@
I 306 How to Change Python's Grammar Hudson
I 333 Python Web Server Gateway Interface v1.0 Eby
I 339 How to Change CPython's Bytecode Cannon
+ I 356 Python 2.5 Release Schedule Norwitz, et al
I 3000 Python 3.0 Plans Kuchling, Cannon
Accepted PEPs (accepted; may not be implemented yet)
@@ -406,6 +407,7 @@
S 353 Using ssize_t as the index type von Loewis
S 354 Enumerations in Python Finney
S 355 Path - Object oriented filesystem paths Lindqvist
+ I 356 Python 2.5 Release Schedule Norwitz, et al
SR 666 Reject Foolish Indentation Creighton
S 754 IEEE 754 Floating Point Special Values Warnes
I 3000 Python 3.0 Plans Kuchling, Cannon
Added: peps/trunk/pep-0356.txt
==============================================================================
--- (empty file)
+++ peps/trunk/pep-0356.txt Wed Feb 8 07:33:27 2006
@@ -0,0 +1,212 @@
+PEP: 356
+Title: Python 2.5 Release Schedule
+Version: $Revision$
+Author: Neal Norwitz
+Status: Draft
+Type: Informational
+Created: 07-Feb-2006
+Python-Version: 2.5
+Post-History:
+
+Abstract
+
+ This document describes the development and release schedule for
+ Python 2.5. The schedule primarily concerns itself with PEP-sized
+ items. Small features may be added up to and including the first
+ beta release. Bugs may be fixed until the final release.
+
+ There will be at least two alpha releases, two beta releases, and
+ one release candidate. The release date is planned 31 October 2006.
+
+
+Release Manager
+
+ TBD (Anthony Baxter?)
+
+ TBD (Martin von Loewis?) is building the Windows installers,
+ TBD (Fred Drake?) the doc packages,
+ TBD (Sean Reifschneider?) the RPMs.
+
+
+Release Schedule
+
+ alpha 1: June 2006 [planned]
+ alpha 2: July 2006 [planned]
+ beta 1: August 2006 [planned]
+ beta 2: September 2006 [planned]
+ rc 1: October 2006 [planned]
+ final: October 2006 [planned]
+
+
+Completed features for 2.5
+
+ PEP 309: Partial Function Application
+ PEP 314: Metadata for Python Software Packages v1.1
+ (should PEP 314 be marked final?)
+ PEP 341: Unified try-except/try-finally to try-except-finally
+ PEP 342: Coroutines via Enhanced Generators
+
+ - AST-based compiler
+
+ - Add support for reading shadow passwords (www.python.org/sf/579435)
+
+ - any()/all() builtin truth functions
+
+ - new hashlib module add support for SHA-224, -256, -384, and -512
+ (replaces old md5 and sha modules)
+
+
+Planned features for 2.5
+
+ PEP 308: Conditional Expressions
+ PEP 328: Absolute/Relative Imports
+ PEP 343: The "with" Statement
+ PEP 352: Required Superclass for Exceptions
+ PEP 353: Using ssize_t as the index type
+
+
+Deferred until 2.6:
+
+ - None
+
+
+Ongoing tasks
+
+ The following are ongoing TO-DO items which we should attempt to
+ work on without hoping for completion by any particular date.
+
+ - Documentation: complete the distribution and installation
+ manuals.
+
+ - Documentation: complete the documentation for new-style
+ classes.
+
+ - Look over the Demos/ directory and update where required (Andrew
+ Kuchling has done a lot of this)
+
+ - New tests.
+
+ - Fix doc bugs on SF.
+
+ - Remove use of deprecated features in the core.
+
+ - Document deprecated features appropriately and update PEP 3000.
+
+ - Mark deprecated C APIs with Py_DEPRECATED.
+
+ - 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.
+
+
+Open issues
+
+ This PEP needs to be updated and release managers confirmed.
+
+
+Carryover features from Python 2.4
+
+ Are any of these done or planned for 2.5?
+
+ - Deprecate and/or remove the modules listed in PEP 4 (posixfile,
+ gopherlib, pre, others)
+
+ - Remove support for platforms as described in PEP 11.
+
+ - Finish implementing the Distutils bdist_dpkg command. (AMK)
+
+ - It would be nice if the built-in SSL socket type could be used
+ for non-blocking SSL I/O. Currently packages such as Twisted
+ which implement async servers using SSL have to require third-party
+ packages such as pyopenssl.
+
+ - reST is going to be used a lot in Zope3. Maybe it could become
+ a standard library module? (Since reST's author thinks it's too
+ unstable, I'm inclined not to do this.)
+
+
+Carryover features from Python 2.3
+
+ - The import lock could use some redesign. (SF 683658.)
+
+ - A nicer API to open text files, replacing the ugly (in some
+ people's eyes) "U" mode flag. There's a proposal out there to
+ have a new built-in type textfile(filename, mode, encoding).
+ (Shouldn't it have a bufsize argument too?)
+
+ - New widgets for Tkinter???
+
+ Has anyone gotten the time for this? *Are* there any new
+ widgets in Tk 8.4? Note that we've got better Tix support
+ already (though not on Windows yet).
+
+ - PEP 304 (Controlling Generation of Bytecode Files by Montanaro)
+ seems to have lost steam.
+
+ - For a class defined inside another class, the __name__ should be
+ "outer.inner", and pickling should work. (SF 633930. I'm no
+ longer certain this is easy or even right.)
+
+ - Decide on a clearer deprecation policy (especially for modules)
+ and act on it. For a start, see this message from Neal Norwitz:
+ http://mail.python.org/pipermail/python-dev/2002-April/023165.html
+ There seems insufficient interest in moving this further in an
+ organized fashion, and it's not particularly important.
+
+ - 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
+ There hasn't been any progress on this, AFAICT.
+
+ - 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).
+ It seems we can't get consensus on this.
+
+ - PEP 262 Database of Installed Python Packages Kuchling
+
+ This turns out to be useful for Jack Jansen's Python installer,
+ so the database is worth implementing. Code will go in
+ sandbox/pep262.
+
+ - PEP 269 Pgen Module for Python Riehl
+
+ (Some necessary changes are in; the pgen module itself needs to
+ mature more.)
+
+ - 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
+ slowly 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.
+
+ - 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.
+
+ - 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).
+
+ - Make 'as' a keyword. It has been a pseudo-keyword long enough.
+ Too much effort to bother.
+
+
+Copyright
+
+ This document has been placed in the public domain.
+
+
+
+Local Variables:
+mode: indented-text
+indent-tabs-mode: nil
+End:
More information about the Python-checkins
mailing list