[Python-checkins] r56029 - peps/trunk/pep-3000.txt
guido.van.rossum
python-checkins at python.org
Tue Jun 19 02:24:10 CEST 2007
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
=========
More information about the Python-checkins
mailing list