[Python-checkins] peps: Some corrections and clarifications regarding the changes between 2.x and 3.x.
nick.coghlan
python-checkins at python.org
Tue Nov 15 11:06:50 CET 2011
http://hg.python.org/peps/rev/58c40f3cbef1
changeset: 3989:58c40f3cbef1
user: Nick Coghlan <ncoghlan at gmail.com>
date: Tue Nov 15 20:06:39 2011 +1000
summary:
Some corrections and clarifications regarding the changes between 2.x and 3.x. Also, we celebrated Python's 20th birthday last PyCon...
files:
pep-0404.txt | 49 +++++++++++++++++++++++++--------------
1 files changed, 31 insertions(+), 18 deletions(-)
diff --git a/pep-0404.txt b/pep-0404.txt
--- a/pep-0404.txt
+++ b/pep-0404.txt
@@ -56,16 +56,18 @@
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
+Python is (as of this writing) more than 20 years old, and Guido and the
+community have 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
+evolution of the language, and while maintaining full 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`_.
+entirely mechanically by such tools as `2to3`_ (there's also a non-trivial
+subset of the language that will run without modification on both 2.7 and
+3.x).
Because maintaining multiple versions of Python is a significant drag
on the resources of the Python developers, and because the
@@ -85,18 +87,20 @@
Strings and bytes
-----------------
-Python 2's basic original string type are called 8-bit strings, and
+Python 2's basic original strings 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
+sequences. 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. Python 3's unicode support even extends to the
-filesystem, so that non-ASCII file names are natively supported.
+unicodes is provided (the closest we get are a few text-based APIs that
+assume UTF-8 as the default encoding if no encoding is explicitly stated).
+Thus, the core interpreter, its I/O libraries, module names, etc. are clear
+in their distinction between unicode strings and bytes. Python 3's unicode
+support even extends to the filesystem, so that non-ASCII file names are
+natively supported.
This string/bytes clarity is often a source of difficulty in
transitioning existing code to Python 3, because many third party
@@ -122,11 +126,19 @@
Python 2 has two core class hierarchies, often called *classic
classes* and *new-style classes*. The latter allow for such things as
-inheriting from the built-in basic types. However, confusion and
-inconsistencies between the two class types has led Python 3 to drop
-classic classes. Now all classes in Python 3 are *new-style*
-(although that's a misnomer now). There is no need to inherit from
-``object`` or set the default metatype to enable them.
+inheriting from the builtin basic types, support descriptor based tools
+like the ``property`` builtin and provide a generally more sane and coherent
+system for dealing with multiple inheritance. Python 3 provided the
+opportunity to completely drop support for classic classes, so all classes
+in Python 3 automatically use the new-style semantics (although that's a
+misnomer now). There is no need to explicitly inherit from ``object`` or set
+the default metatype to enable them (in fact, setting a default metatype at
+the module level is no longer supported - the default metatype is always
+``object``).
+
+The mechanism for explicitly specifying a metaclass has also changed to use
+a ``metaclass`` keyword argument in the class header line rather than a
+``__metaclass__`` magic attribute in the class body.
Multiple spellings
@@ -142,9 +154,10 @@
Imports
-------
-In Python 3, star imports (e.g. ``from x import *``) are only
-permitted in module level code. Also, only absolute imports are
-supported.
+In Python 3, implicit relative imports within packages are no longer
+available - only absolute imports and explicit relative imports are
+supported. In addition, star imports (e.g. ``from x import *``) are only
+permitted in module level code.
Also, some areas of the standard library have been reorganized to make
the naming scheme more intuitive. Some rarely used builtins have been
--
Repository URL: http://hg.python.org/peps
More information about the Python-checkins
mailing list