Some corrections and clarifications regarding the changes between 2.x and 3.x. Also, we celebrated Python's 20th birthday last PyCon...

pep-0404.txt

@@ -56,16 +56,18 @@ 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
+Python is (as of this writing) more than 20 years old, and Guido and the
-community has learned a lot in those intervening years.  Guido's
+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 @@ to Python 3.
 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,
+unicodes is provided (the closest we get are a few text-based APIs that
-module names, etc. are clear in their distinction between unicode
+assume UTF-8 as the default encoding if no encoding is explicitly stated).
-strings and bytes.  Python 3's unicode support even extends to the
+Thus, the core interpreter, its I/O libraries, module names, etc. are clear
-filesystem, so that non-ASCII file names are natively supported.
+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 @@ Classes
 
 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
+inheriting from the builtin basic types, support descriptor based tools
-inconsistencies between the two class types has led Python 3 to drop
+like the ``property`` builtin and provide a generally more sane and coherent
-classic classes.  Now all classes in Python 3 are *new-style*
+system for dealing with multiple inheritance.  Python 3 provided the
-(although that's a misnomer now).  There is no need to inherit from
+opportunity to completely drop support for classic classes, so all classes
-``object`` or set the default metatype to enable them.
+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 @@ were kept).
 Imports
 -------
 
-In Python 3, star imports (e.g. ``from x import *``) are only
+In Python 3, implicit relative imports within packages are no longer
-permitted in module level code.  Also, only absolute imports are
+available - only absolute imports and explicit relative imports are
-supported.
+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