Author: guido.van.rossum Date: Tue Jun 19 02:24:07 2007 New Revision: 56029 Modified: peps/trunk/pep-3000.txt Log: Update the schedule. Give more detail about compatibility and transition. Add a References section. Modified: peps/trunk/pep-3000.txt ============================================================================== --- peps/trunk/pep-3000.txt (original) +++ peps/trunk/pep-3000.txt Tue Jun 19 02:24:07 2007 @@ -48,13 +48,19 @@ Timeline ======== -I no longer think we need a meta-PEP for the Python 3000 timeline; -instead, here's my current proposal. I hope to have a first alpha -release (3.0a1) out in the first half of 2007; it should take no more -than a year from then before the first proper release, named Python -3.0. I would like all PEPs for features going into Python 3000 to be -submitted by the end of April 2007 (allowing time for discussion and -implementation after the initial submission). +Past deadlines: + +* April 2007: feature PEPs submitted (except library reform proposals). + +Hopeful future deadlines: + +* August 2007: release 3.0a1. +* December 2007: release 2.6a1. +* April 2008: full feature freeze. +* June 2008: release 2.6 (final). +* August 2008: release 3.0 (final). + +See PEP 361 for more details on the Python 2.6 release schedule. Note: standard library development is expected to ramp up after 3.0a1 is released; it is exempt from the April 2007 PEP deadline. @@ -77,27 +83,51 @@ Compatibility and Transition ============================ -We need a meta-PEP to describe the compatibility requirements. Python -3000 will break backwards compatibility. There is no requirement that -Python 2.9 code will run unmodified on Python 3.0. - -I'm not sure whether it is reasonable to require that Python 2.x code -can be mechanically translated to equivalent Python 3.0 code; Python's -dynamic typing combined with the plans to change the semantics of -certain methods of dictionaries, for example, would make this task -really hard. However, it would be great if there was some tool that -did at least an 80% job of translation, pointing out areas where it -wasn't sure using comments or warnings. Perhaps such a tool could be -based on something like Pychecker. - -Another kind of tool could be an instrumented version of 2.x which -produces run-time warnings about constructs that will get a different -meaning in 3.0. This can't be used for all incompatibilities, but -it's likely to help reach a larger percentage of correct translations. -(This approach is already in place for detecting reliance on '/' to do -integer division; see Tools/scripts/fixdiv.py, which finds occurrences -of int/int and long/long that were flagged by running your program -with -Qwarnall.) +Python 3.0 will break backwards compatibility with Python 2.x. + +**There is no requirement that Python 2.6 code will run unmodified on +Python 3.0.** Not even a subset. (Of course there will be a *tiny* +subset, but it will be missing major functionality.) + +Python 2.6 will support forward compatibility in the following two +ways: + +* It will support a "Py3k warnings mode" which will warn dynamically + (i.e. at runtime) about features that will stop working in Python + 3.0, e.g. assuming that range() returns a list. +* It will contain backported versions of many Py3k features, either + enabled through __future__ statements or simply by allowing old and + new syntax to be used side-by-side (if the new syntax would be a + syntax error in 2.x). + +Instead, and complementary to the forward compatibility features in +2.6, there will be a separate source code conversion tool [1]_. This +tool can do a context-free source-to-source translation. For example, +it can translate ``apply(f, args)`` into ``f(*args)``. However, the +tool cannot do data flow analysis or type inferencing, so it simply +assumes that ``apply`` in this example refers to the old built-in +function. + +The recommended development model for a project that needs to support +Python 2.6 and 3.0 imultaneously is as follows: + +0. You should have excellent unit tests with close to full coverage. +1. Port your project to Python 2.6. +2. Turn on the Py3k warnings mode. +3. Test and edit until no warnings remain. +4. Use the 2to3 tool to convert this source code to 3.0 syntax. + **Do not manually edit the output!** +5. Test the converted source code under 3.0. +6. If problems are found, make corrections to the **2.6** version + of the source code and go back to step 3. +7. When it's time to release, release separate 2.6 and 3.0 tarballs + (or whatever archive form you use for releases). + +It is recommended not to edit the 3.0 source code until you are ready +to reduce 2.6 support to pure maintenance (i.e. the moment when you +would normally move the 2.6 code to a maintenance branch anyway). + +PS. We need a meta-PEP to describe the transitional issues in detail. Implementation Language @@ -105,7 +135,7 @@ Python 3000 will be implemented in C, and the implementation will be derived as an evolution of the Python 2 code base. This reflects my -views (which I share with Joel Spolsky) on the dangers of complete +views (which I share with Joel Spolsky [2]_) on the dangers of complete rewrites. Since Python 3000 as a language is a relatively mild improvement on Python 2, we can gain a lot by not attempting to reimplement the language from scratch. I am not against parallel @@ -121,6 +151,16 @@ topics are even more welcome! +References +========== + +.. [1] The 2to3 tool, in the subversion sandbox + http://svn.python.org/view/sandbox/trunk/2to3/ + +.. [2] Joel on Software: Things You Should Never Do, Part I + http://www.joelonsoftware.com/articles/fog0000000069.html + + Copyright =========