Python 3
From Wikipedia, the free encyclopedia
Python 3, an interpreted programming language, is currently being developed by Guido van Rossum. It will be fully dynamically typed and use automatic memory management, as the current version. It is thus similar to Perl, Ruby, Scheme, Smalltalk, and Tcl. Python is developed as an open source project, managed by the non-profit Python Software Foundation.
Paradigm: | Multi-paradigm |
---|---|
Designed by: | Guido van Rossum |
Developer: | Python Software Foundation |
OS: | Cross-platform |
License: | Python Software Foundation License |
Website: | www.python.org |
Contents |
[edit] Philosophy
Python 3 is being developed with the same philosophy as in prior versions, so any reference to Python philosophy will apply to Python 3 as well. However, as Python has accumulated new and redundant ways to program the same task, Python 3 has an emphasis on removing duplicative constructs and modules, in keeping with "There should be one—and preferably only one—obvious way to do it".
Nonetheless, Python 3 will remain a multi-paradigm language. Coders will still have options among object orientation, structured programming, functional programming, and aspect-oriented programming and other paradigms; but within such broad choices, the details are intended to be more obvious in Python 3 than they have become in Python 2.x.
[edit] History
- See article: Python programming language
[edit] Python 3
[edit] Naming
Python 3 (or more formally, for the initial release, Python 3.0), Python 3000, and Py3K are all names for the upcoming version of the Python programming language. The project is called Python 3000, or abbreviated as Py3k. Once released, it will be officially referred to as Python 3.0, which is what "python3.0 -V" will print; the actual file names will use the same naming convention used for Python 2.x. There won't be a new name for the executable, and the suffix for Python source files will remain the same.
[edit] Timeline
Guido van Rossum, Python's designer, hopes to release a first alpha release of a "meta-PEP" timeline sometime in 2007; it may take another year after that (or more) before the first proper release, named Python 3.0.
Parallel Python 2.x and 3.x releases are expected to exist for some time; the Python 2.x releases continuing for a longer time than the traditional 2.x.y bugfix releases. Typically, there are no further bugfix releases for version 2.x once version 2.(x+1) is released, but there are expected 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 extent 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.
[edit] Compatibility and transition
Python 3 will break backward compatibility. There is no requirement that Python 2.x code will run unmodified on Python 3.0. Python's dynamic typing combined with the plans to change the semantics of certain methods of dictionaries, for example, would make mechanical translation from Python 2.x to Python 3.0 very difficult. However, consideration is being given to develop a tool that does at least an 80% job of translation, pointing out areas where it wasn't sure using comments or warnings. Such a tool may be based on existing Python static code analysis tools.
Note that while there is no explicit requirement that code be able to run unmodified in both versions, in practice it is quite likely for most code. As of January 2007, it looks like most reasonable code should run quite well under either branch.
Another kind of tool that may be developed is an instrumented version of 2.x that 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.
[edit] What's new
Plans for Python 3 include:
- moving map, filter and reduce out of the built-in namespace (the rationale being that map and filter are expressed more clearly as list comprehensions, and reduce more clearly as an accumulation loop)
- adding support for optional type declarations.
- unifying the
str
/unicode
types, and introducing a separate mutablebytes
type - converting built-ins to returning iterators (instead of lists), where appropriate
- removing backward-compatibility features like classic classes, classic division, string exceptions, and implicit relative imports
[edit] Python Enhancement Proposal 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 is special; it is the meta-PEP for Python 3000 meta-PEPs (it describes 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 formal Python 3000 development began. PEP 3099 is a list of features that will not change (but which several people asked about).