PEP: 320 Title: Python 2.4 Release Schedule Version: $Revision$ Author: Barry Warsaw Status: Incomplete Type: Informational Created: 29-Jul-2003 Python-Version: 2.4 Post-History: Abstract 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. Other than that, no claims are made on release plans, nor what will actually be in Python 2.4 at this early date. There were 19 months between the Python 2.2 final and Python 2.3 final releases. If that schedule holds true for Python 2.4, you can expect it some time around February 2005. Release Manager TBD Completed features for 2.4 None Planned features for 2.4 Too early for anything more to get done here. 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. - 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 None at this time. Carryover features from Python 2.3 - The import lock could use some redesign. (SF 683658.) - Set API issues; is the sets module perfect? I expect it's good enough to stop polishing it until we've had more widespread user experience. - 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?) Ditto. - 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). - Fredrik Lundh's basetime proposal: http://effbot.org/ideas/time-type.htm I believe this is dead now. - 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.) - 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.) - 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 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. - Deprecate the buffer object. http://mail.python.org/pipermail/python-dev/2002-July/026388.html http://mail.python.org/pipermail/python-dev/2002-July/026408.html It seems that this is never going to be resolved. - PEP 269 Pgen Module for Python Riehl (Some necessary changes are in; the pgen module itself needs to mature more.) - Add support for the long-awaited Python catalog. Kapil Thangavelu has a Zope-based implementation that he demoed at OSCON 2002. Now all we need is a place to host it and a person to champion it. (Some changes to distutils to support this are in, at least.) - 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/ - 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: