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
|
||||
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
|
||||
|
@ -48,12 +49,111 @@ Upgrade path
|
|||
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
|
||||
=========
|
||||
|
||||
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:
|
||||
|
|
Loading…
Reference in New Issue