Abstract

This PEP sets guidelines for Python 3000 development. Ideally, wefirst agree on the process, and start discussing features only afterthe process has been decided and specified. In practice, we’ll bediscussing features and process simultaneously; often the debate abouta particular feature will prompt a process discussion.

Naming

Python 3000, Python 3.0 and Py3K are all names for the same thing.The project is called Python 3000, or abbreviated to Py3k. The actualPython release will be referred to as Python 3.0, and that’swhat “python3.0 -V” will print; the actual file names will use thesame naming convention we use for Python 2.x. I don’t want to pick anew name for the executable or change the suffix for Python sourcefiles.

PEP Numbering

Python 3000 PEPs are numbered starting atPEP 3000. PEPs 3000-3099are meta-PEPs – these can be either process or informational PEPs.PEPs 3100-3999 are feature PEPs.PEP 3000 itself (this PEP) isspecial; it is the meta-PEP for Python 3000 meta-PEPs (IOW it describethe process to define processes).PEP 3100 is also special; it’s alaundry list of features that were selected for (hopeful) inclusion inPython 3000 before we started the Python 3000 process for real. PEP3099, finally, is a list of features that willnot change.

Timeline

SeePEP 361, which contains the release schedule for Python2.6 and 3.0. These versions will be released in lockstep.

Note: standard library development is expected to ramp up after 3.0a1is released.

I expect that there will be parallel Python 2.x and 3.x releases forsome time; the Python 2.x releases will continue for a longer timethan the traditional 2.x.y bugfix releases. Typically, we stopreleasing bugfix versions for 2.x once version 2.(x+1) has beenreleased. But I expect there to be at least one or two new 2.xreleases even after 3.0 (final) has been released, probably well into3.1 or 3.2. This will to some extent depend on community demand forcontinued 2.x support, acceptance and stability of 3.0, and volunteerstamina.

I expect that Python 3.1 and 3.2 will be released much sooner after3.0 than has been customary for the 2.x series. The 3.x releasepattern will stabilize once the community is happy with 3.x.

Compatibility and Transition

Python 3.0 will break backwards compatibility with Python 2.x.

There is no requirement that Python 2.6 code will run unmodified onPython 3.0. Not even a subset. (Of course there will be atinysubset, but it will be missing major functionality.)

Python 2.6 will support forward compatibility in the following twoways:

• It will support a “Py3k warnings mode” which will warn dynamically(i.e. at runtime) about features that will stop working in Python3.0, e.g. assuming that range() returns a list.
• It will contain backported versions of many Py3k features, eitherenabled through __future__ statements or simply by allowing old andnew syntax to be used side-by-side (if the new syntax would be asyntax error in 2.x).

Instead, and complementary to the forward compatibility features in2.6, there will be a separate source code conversion tool[1]. Thistool can do a context-free source-to-source translation. For example,it can translateapply(f,args) intof(*args). However, thetool cannot do data flow analysis or type inferencing, so it simplyassumes thatapply in this example refers to the old built-infunction.

The recommended development model for a project that needs to supportPython 2.6 and 3.0 simultaneously 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 the2.6 versionof 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 readyto reduce 2.6 support to pure maintenance (i.e. the moment when youwould 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

Python 3000 will be implemented in C, and the implementation will bederived as an evolution of the Python 2 code base. This reflects myviews (which I share with Joel Spolsky[2]) on the dangers of completerewrites. Since Python 3000 as a language is a relatively mildimprovement on Python 2, we can gain a lot by not attempting toreimplement the language from scratch. I am not against parallelfrom-scratch implementation efforts, but my own efforts will bedirected at the language and implementation that I know best.

Meta-Contributions

Suggestions for additional text for this PEP are gracefully acceptedby the author. Draft meta-PEPs for the topics above and additionaltopics are even more welcome!

References

Copyright

This document has been placed in the public domain.