diff --git a/pep-0320.txt b/pep-0320.txt new file mode 100644 index 000000000..b561c8229 --- /dev/null +++ b/pep-0320.txt @@ -0,0 +1,184 @@ +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: