PEP: 283 Title: Python 2.3 Release Schedule Version: $Revision$ Author: Guido van Rossum Status: Incomplete Type: Informational Created: 27-Feb-2002 Python-Version: 2.3 Post-History: 27-Feb-2002 Abstract This document describes the development and release schedule for Python 2.3. The schedule primarily concerns itself with PEP-sized items. Small features may be added until the first beta release. Bugs may be fixed until the final release. There is currently no defined schedule. We hope to release at least the first alpha before OSCON 2002, and the final release before the end of 2002, but if important projects below are delayed, the release may be delayed. There will be at least two alpha releases, two beta releases, and one release candidate. Alpha and beta releases will be spaced at least 4 weeks apart (except if an emergency release must be made to correct a blunder in the previous release; then the blunder release does not count). Release candidates will be spaced at least one week apart (excepting again blunder corrections). Release Manager Barry Warsaw. (Didn't have his finger on his nose in time. :) Planned features for 2.3 Here are a few PEPs and other ideas under consideration, with comments in "parade of the PEPs" style. Not all of these will be part of the final 2.3 release; we'll update the list as decisions crystallize. (There's also a bunch of things already implemented, like bool, PyMalloc, and universal newlines.) This is pretty much an unordered laundry list. Please send feedback to python-dev@python.org; I hope to maintain this for the life of the 2.3 development process. - 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/ - PEP 269 Pgen Module for Python Riehl I haven't heard from Jon Riehl, so I consider dropping this idea. - PEP 273 Import Modules from Zip Archives Ahlstrom I think this is close -- maybe it's already checked in and I don't know about it! - PEP 282 A Logging System Mick Vinay Sajip has been making steady progress on an implementation, and despite a recent near-flamewar (which I haven't followed) I expect that his code will be incorporated in the near future. - PEP 263 Defining Python Source Code Encodings I'm all for this plan. I haven't reviewed the implementation. - PEP 218 Adding a Built-In Set Object Type I think it would be good to revive this in some form, using a module rather than a built-in type. - A new command line option parser. Greg Ward's Optik (http://optik.sf.net) would fit the bill fine; there's only some question about whether it should be given a less "cutesy" name. See also http://www.python.org/sigs/getopt-sig/ - 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 - Extended slice notation for all built-in sequences. A patch by Michael Hudson has solved this, mostly; there's an open issue about slice assignments where the source has a different length than the destination, as in L[:5:] = range(10). - An iterator tools module featuring goodies from SML and Haskell? http://mail.python.org/pipermail/python-dev/2002-May/024418.html - Speed up list iterations by filling tp_iter and other tweaks? http://www.python.org/sf/560736 (This is done; also for xrange.) - 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 - Lazily tracking tuples? http://mail.python.org/pipermail/python-dev/2002-May/023926.html http://www.python.org/sf/558745 - Timeoutsocket. Work in progress. http://mail.python.org/pipermail/python-dev/2002-May/024077.html http://www.python.org/sf/555085 (Most of this is done, but we still need to add a global timeout option.) - Making None a keyword. Can't be done right away, but a warning would be a first step. http://mail.python.org/pipermail/python-dev/2002-April/023600.html Ditto for 'as', which has been a pseudo-keyword long enough. - Stage 2 of the int/long integration (PEP 237). This mostly means warning about situations where hex, oct or shift of an int returns a different value than for the same value as a long. I propose *not* to change the semantics this time; that will happen in the next release, still with a warning. (I think the PEP misses this step, but it's necessary -- we can't just change the semantics silently without warning first.) Does this need a __future__ statement??? - Nuke SET_LINENO from all code objects (providing a different way to set debugger breakpoints). This can boost pystone by >5%. (Tim Peters.) - Write a pymemcompat.h that people can bundle with their extensions and then use the 2.3 memory interface with all Pythons in the range 1.5.2 to 2.3. (Michael Hudson has done this; it's in Misc/pymemcompat.h.) - PEP 262 Database of Installed Python Packages Kuchling Andrew is still hopeful that he'll implement this. - Add support for the long-awaited Python catalog. Kapil Thangavelu is working on an implementation (he's planning a demo for OSCON 2002). What else is needed? - 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). - Warn when an extension type's tp_compare returns anything except -1, 0 or 1. http://www.python.org/sf/472523 (This is done.) - A standard datetime type. An implementation effort is under way: http://www.zope.org/Members/fdrake/DateTimeWiki/FrontPage Effbot and MAL have a proposal for a basic interface that all datetime types should implement, but there are some problems with UTC. A decision needs to be made. - 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 - Add a new concept, "pending deprecation", with associated warning PendingDeprecationWarning. This warning is normally suppressed, but can be enabled by a suitable -W option. (This has been added now, but nothing uses it yet.) - 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). - Documentation: complete the distribution and installation manuals. - Documentation: complete the documentation for new-style classes. - Look over the Demos/ directory and update where required. - New tests. - Fix doc bugs on SF. - Remove use of deprecated features in the core. - Doc deprecated features appropriately - Move deprecated features under Py_DEPRECATED (or whatever is decided) - 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. Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil End: