And now for something completely different.
This commit is contained in:
parent
c404fb12fc
commit
e459ae2a03
102
pep-0404.txt
102
pep-0404.txt
|
@ -39,7 +39,8 @@ Official pronouncement
|
||||||
======================
|
======================
|
||||||
|
|
||||||
Rule number six: there is *no* official Python 2.8 release. There never will
|
Rule number six: there is *no* official Python 2.8 release. There never will
|
||||||
be an official Python 2.8 release. It is an ex-release.
|
be an official Python 2.8 release. It is an ex-release. Python 2.7
|
||||||
|
is the end of the Python 2 line of development.
|
||||||
|
|
||||||
|
|
||||||
Upgrade path
|
Upgrade path
|
||||||
|
@ -48,12 +49,111 @@ Upgrade path
|
||||||
The official upgrade path from Python 2.7 is to Python 3.
|
The official upgrade path from Python 2.7 is to Python 3.
|
||||||
|
|
||||||
|
|
||||||
|
And Now For Something Completely Different
|
||||||
|
==========================================
|
||||||
|
|
||||||
|
In all seriousness, there are important reasons why there won't be an
|
||||||
|
official Python 2.8 release, and why you should plan to migrate
|
||||||
|
instead to Python 3.
|
||||||
|
|
||||||
|
Python is (as of this writing) nearly 20 years old, and Guido and the
|
||||||
|
community has learned a lot in those intervening years. Guido's
|
||||||
|
original concept for Python 3 was to make changes to the language
|
||||||
|
primarily to remove the warts that had grown in the preceding
|
||||||
|
versions. Python 3 was not to be a complete redesign, but instead an
|
||||||
|
evolution of the language, and while maintaining backward
|
||||||
|
compatibility with Python 2 was explicitly off-the-table, neither were
|
||||||
|
gratuitous changes in syntax or semantics acceptable. In most cases,
|
||||||
|
Python 2 code can be translated fairly easily to Python 3, sometimes
|
||||||
|
entirely mechanically by such tools as `2to3`_.
|
||||||
|
|
||||||
|
Because maintaining multiple versions of Python is a significant drag
|
||||||
|
on the resources of the Python developers, and because the
|
||||||
|
improvements to the language and libraries embodied in Python 3 are so
|
||||||
|
important, it was decided to end the Python 2 lineage with Python
|
||||||
|
2.7. Thus, all new development occurs in the Python 3 line of
|
||||||
|
development, and there will never be an official Python 2.8 release.
|
||||||
|
Python 2.7 will however be maintained for longer than the usual period
|
||||||
|
of time.
|
||||||
|
|
||||||
|
Here are some highlights of the significant improvements in Python 3.
|
||||||
|
You can read in more detail on the differences_ between Python 2 and
|
||||||
|
Python 3. There are also many good guides on porting_ from Python 2
|
||||||
|
to Python 3.
|
||||||
|
|
||||||
|
|
||||||
|
Strings and bytes
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
Python 2's basic original string type are called 8-bit strings, and
|
||||||
|
they play a dual role in Python 2 as both ASCII text and as byte
|
||||||
|
arrays. While Python 2 also has a unicode string type, the
|
||||||
|
fundamental ambiguity of the core string type, coupled with Python 2's
|
||||||
|
default behavior of supporting automatic coercion from 8-bit strings
|
||||||
|
to unicodes when the two are combined, often leads to `UnicodeError`s.
|
||||||
|
Python 3's standard string type is a unicode, and Python 3 adds a
|
||||||
|
bytes type, but critically, no automatic coercion between bytes and
|
||||||
|
unicodes is provided. Thus, the core interpreter, its I/O libraries,
|
||||||
|
module names, etc. are clear in their distinction between unicode
|
||||||
|
strings and bytes. This clarity is often a source of difficulty in
|
||||||
|
transitioning existing code to Python 3, because many third party
|
||||||
|
libraries and applications are themselves ambiguous in this
|
||||||
|
distinction. Once migrated though, most `UnicodeError`s can be
|
||||||
|
eliminated.
|
||||||
|
|
||||||
|
|
||||||
|
Numbers
|
||||||
|
-------
|
||||||
|
|
||||||
|
Python 2 has two basic integer types, a native machine-sized `int`
|
||||||
|
type, and an arbitrary length `long` type. These have been merged in
|
||||||
|
Python 3 into a single `int` type analogous to Python 2's `long`
|
||||||
|
type.
|
||||||
|
|
||||||
|
In addition, integer division now produces floating point numbers for
|
||||||
|
non-integer results.
|
||||||
|
|
||||||
|
|
||||||
|
Multiple spellings
|
||||||
|
------------------
|
||||||
|
|
||||||
|
There are many cases in Python 2 where multiple spellings of some
|
||||||
|
constructs exist, such as `repr()` and *backticks*, or the two
|
||||||
|
inequality operators `!=` and `<>`. In all cases, Python 3 has chosen
|
||||||
|
exactly one spelling and removed the other (e.g. `repr()` and `!=`
|
||||||
|
were kept).
|
||||||
|
|
||||||
|
|
||||||
|
Imports
|
||||||
|
-------
|
||||||
|
|
||||||
|
In Python 3, star imports (e.g. ``from x import *``) are only
|
||||||
|
premitted in module level code. Also, only absolute imports are
|
||||||
|
supported.
|
||||||
|
|
||||||
|
Also, some areas of the standard library have been reorganized to make
|
||||||
|
the naming scheme more intuitive. Some rarely used builtins have been
|
||||||
|
relocated to standard library modules.
|
||||||
|
|
||||||
|
|
||||||
|
Iterators and views
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
Many APIs, which in Python 2 returned concrete lists, in Python 3 now
|
||||||
|
return iterators or lightweight *views*.
|
||||||
|
|
||||||
|
|
||||||
Copyright
|
Copyright
|
||||||
=========
|
=========
|
||||||
|
|
||||||
This document has been placed in the public domain.
|
This document has been placed in the public domain.
|
||||||
|
|
||||||
|
|
||||||
|
.. _`2to3`: http://docs.python.org/library/2to3.html
|
||||||
|
.. _differences: http://docs.python.org/release/3.0.1/whatsnew/3.0.html
|
||||||
|
.. _porting: http://python3porting.com/
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
..
|
..
|
||||||
Local Variables:
|
Local Variables:
|
||||||
|
|
Loading…
Reference in New Issue