2006-04-05 16:06:03 -04:00
|
|
|
|
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 binary, once it is released, will be named Python 3.0.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
2006-04-05 16:14:12 -04:00
|
|
|
|
PEPs 3100-3999 are feature PEPs. PEP 3000 itself (this PEP) is
|
2006-04-05 16:06:03 -04:00
|
|
|
|
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
|
|
|
|
|
|
========
|
|
|
|
|
|
|
|
|
|
|
|
We need a meta-PEP for the Python 3000 timeline. At this moment, I
|
|
|
|
|
|
hope to have a first alpha release out sometime in 2007; it may take
|
|
|
|
|
|
another year after that (or more) before the first proper release,
|
|
|
|
|
|
named Python 3.0.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
It's quite possible 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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:
|
