136 lines
4.9 KiB
Plaintext
136 lines
4.9 KiB
Plaintext
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).
|
||
|
||
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:
|