Update the schedule. Give more detail about compatibility and transition.

Add a References section.

pep-3000.txt

@@ -48,13 +48,19 @@ Python 3000 before we started the Python 3000 process for real.  PEP
 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 @@ pattern will stabilize once the community is happy with 3.x.
 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.
+Python 3.0 will break backwards compatibility with Python 2.x.
 
-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.
+**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.)
 
-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 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 @@ Implementation Language
 
 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 @@ by the author.  Draft meta-PEPs for the topics above and additional
 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
 =========