python-peps/pep-3000.txt

PEP: 3000
Title: Python 3000
Version: $Revision$
Last-Modified: $Date$
Author: Guido van Rossum <guido@python.org>
Status: Active
Type: Process
Content-Type: text/x-rst
Created: 05-Apr-2006
Post-History: 


Abstract
========

This PEP sets guidelines for Python 3000 development.  Ideally, we
first agree on the process, and start discussing features only after
the process has been decided and specified.  In practice, we'll be
discussing features and process simultaneously; often the debate about
a 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 actual
Python release will be referred to as Python 3.0, and that's
what "python3.0 -V" will print; the actual file names will use the
same naming convention we use for Python 2.x.  I don't want to pick a
new name for the executable or change the suffix for Python source
files.


PEP Numbering
=============

Python 3000 PEPs are numbered starting at PEP 3000.  PEPs 3000-3099
are meta-PEPs -- these can be either process or informational PEPs.
PEPs 3100-3999 are feature PEPs.  PEP 3000 itself (this PEP) is
special; it is the meta-PEP for Python 3000 meta-PEPs (IOW it describe
the process to define processes).  PEP 3100 is also special; it's a
laundry list of features that were selected for (hopeful) inclusion in
Python 3000 before we started the Python 3000 process for real.  PEP
3099, finally, is a list of features that will *not* change.


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).

Note: standard library development is expected to ramp up after 3.0a1
is released; it is exempt from the April 2007 PEP deadline.

I expect that there will be parallel Python 2.x and 3.x releases for
some time; the Python 2.x releases will continue for a longer time
than the traditional 2.x.y bugfix releases.  Typically, we stop
releasing bugfix versions for 2.x once version 2.(x+1) has been
released.  But I expect there to be at least one or two new 2.x
releases even after 3.0 (final) has been released, probably well into
3.1 or 3.2.  This will to some extend depend on community demand for
continued 2.x support, acceptance and stability of 3.0, and volunteer
stamina.

I expect that Python 3.1 and 3.2 will be released much sooner after
3.0 than has been customary for the 2.x series.  The 3.x release
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.

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.)


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
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
from-scratch implementation efforts, but my own efforts will be
directed at the language and implementation that I know best.


Meta-Contributions
==================

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


Copyright
=========

This document has been placed in the public domain.



..
   Local Variables:
   mode: indented-text
   indent-tabs-mode: nil
   sentence-end-double-space: t
   fill-column: 70
   coding: utf-8
   End: