This document describes the development and release schedule for
Python 2.4. 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 was 30th November, 2004.

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.

AST-based compiler: this branch was not completed in time for
2.4, but will land on the trunk some time after 2.4 final is
out, for inclusion in 2.5.

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
instable, I'm inclined not to do this.)

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. ([3]. 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 [4].
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 [5].
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.

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.