pep-0414 -> accepted and added two things brought up on the mailinglist

pep-0414.txt

@@ -3,10 +3,11 @@ Title: Explicit Unicode Literal for Python 3.3
 Version: $Revision$
 Last-Modified: $Date$
 Author: Armin Ronacher <armin.ronacher@active-4.com>
-Status: Draft
+Status: Accepted
 Type: Standards Track
 Content-Type: text/x-rst
 Created: 15-Feb-2012
+Post-History: 28-Feb-2012
 
 
 Abstract
@@ -18,6 +19,12 @@ enable side-by-side support of libraries for both Python 2 and Python 3
 without the need for an explicit 2to3 run.
 
 
+BDFL Pronouncement
+==================
+
+This PEP has been formally accepted for Python 3.3.
+
+
 Rationale and Goals
 ===================
 
@@ -49,16 +56,19 @@ In Python 2.7 these string types can be defined explicitly.  Without any
 future imports ``b'foo'`` means bytestring, ``u'foo'`` declares a unicode
 string and ``'foo'`` a native string which in Python 2.x means bytes.
 With the ``unicode_literals`` import the native string type is no longer
-available and has to be incorrectly labeled as bytestring.  If such a
+available by syntax and has to be incorrectly labeled as bytestring.  If
-codebase is then used in Python 3, the interpreter will start using byte
+such a codebase is then used in Python 3, the interpreter will start using
-objects in places where they are no longer accepted (such as identifiers).
+byte objects in places where they are no longer accepted (such as
-This can be solved by a module that detects 2.x and 3.x and provides
+identifiers).  This can be solved by a module that detects 2.x and 3.x and
-wrapper functions that transcode literals at runtime.  Unfortunately, this
+provides wrapper functions that transcode literals at runtime (either by
-has the side effect of slowing down the runtime performance of Python and
+having a ``u`` function that marks things as unicode without future
-makes for less beautiful code.  Considering that Python 2 and Python 3
+imports or the inverse by having a ``n`` function that marks strings as
-support for most libraries will have to continue side by side for several
+native).  Unfortunately, this has the side effect of slowing down the
-more years to come, this means that such modules lose one of Python's key
+runtime performance of Python and makes for less beautiful code.
-properties: easily readable and understandable code.
+Considering that Python 2 and Python 3 support for most libraries will
+have to continue side by side for several more years to come, this means
+that such modules lose one of Python's key properties: easily readable and
+understandable code.
 
 Additionally, the vast majority of people who maintain Python 2.x
 codebases are more familiar with Python 2.x semantics, and a per-file
@@ -126,9 +136,9 @@ Problems with 2to3
 In practice 2to3 currently suffers from a few problems which make it
 unnecessarily difficult and/or unpleasant to use:
 
--   Bad overall performance.  In many cases 2to3 runs one or two orders of
+-   Bad overall performance.  In many cases 2to3 runs 20 times slower than
-    magnitude slower than the testsuite for the library or application
+    the testsuite for the library or application it's testing.  (This for
-    it's testing.
+    instance is the case for the Jinja2 library).
 -   Slightly different behaviour in 2to3 between different versions of
     Python cause different outcomes when paired with custom fixers.
 -   Line numbers from error messages do not match up with the real source