Very draft version of 2.5 release schedule.

pep-0000.txt

@@ -60,6 +60,7 @@ Index by Category
  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 @@ Numerical Index
  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

pep-0356.txt

@@ -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: