python-peps/pep-0356.txt

219 lines
6.9 KiB
Plaintext
Raw Normal View History

PEP: 356
Title: Python 2.5 Release Schedule
Version: $Revision$
2006-02-10 16:39:54 -05:00
Author: Neal Norwitz, GvR
Status: Draft
Type: Informational
Created: 07-Feb-2006
Python-Version: 2.5
Post-History:
Abstract
2006-02-10 16:39:54 -05:00
(GvR: I'm sprinkling questions like this throughout this document.
I'll remove them again once the questions are answered.)
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 30 September 2006.
Release Manager
TBD (Anthony Baxter?)
2006-02-08 01:52:00 -05:00
Martin von Loewis is building the Windows installers,
TBD (Fred Drake?) the doc packages,
TBD (Sean Reifschneider?) the RPMs.
Release Schedule
(GvR: perhaps one month earlier? If change, update abstract)
2006-02-10 16:39:54 -05:00
alpha 1: May 6, 2006 [planned]
alpha 2: June 3, 2006 [planned]
alpha 3: July 1, 2006 [planned]
beta 1: July 29, 2006 [planned]
beta 2: August 26, 2006 [planned]
rc 1: September 16, 2006 [planned]
final: September 30, 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
2006-02-09 03:22:57 -05:00
- Add support for reading shadow passwords (http://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)
2006-02-08 22:59:44 -05:00
- new cProfile module suitable for profiling long running applications
with minimal overhead
Planned features for 2.5
2006-02-10 16:39:54 -05:00
PEP 308: Conditional Expressions.
(GvR: who is volunteering?)
PEP 328: Absolute/Relative Imports
2006-02-10 16:39:54 -05:00
(GvR: who is volunteering?)
PEP 343: The "with" Statement
2006-02-10 16:39:54 -05:00
(GvR: who is volunteering? Is MWH's hack/patch available?)
PEP 352: Required Superclass for Exceptions
2006-02-10 16:39:54 -05:00
(GvR: who is volunteering? Maybe Brett?)
PEP 353: Using ssize_t as the index type
2006-02-10 16:39:54 -05:00
MvL expects this to be complete in March.
Access to C AST from Python
2006-02-10 16:39:54 -05:00
(GvR: I have a bunch more that could/would/should be added.)
2006-02-14 14:27:27 -05:00
Add bdist_msi to the distutils package. (MvL wants one more
independent release first.)
Add bdist_deb to the distutils package? (Who's the author?)
Add bdist_egg to the distutils package???
Add setuptools to the standard library.
2006-02-14 15:00:33 -05:00
Add wsgiref to the standard library.
Deferred until 2.6:
- None
Open issues
This PEP needs to be updated and release managers confirmed.
Carryover features from Python 2.4
2006-02-10 16:39:54 -05:00
(GvR: should we just drop this section and reject the PEPs/patches?)
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
2006-02-10 16:39:54 -05:00
(GvR: should we just drop this section and reject the PEPs/patches?)
- 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: