[Python-checkins] peps: pep-0414 -> accepted and added two things brought up on the mailinglist

[armin.ronacher]

http://hg.python.org/peps/rev/969346766784
changeset:   4092:969346766784
parent:      4083:606470f2d09a
user:        Armin Ronacher <armin.ronacher at active-4.com>
date:        Tue Feb 28 08:18:52 2012 +0000
summary:
  pep-0414 -> accepted and added two things brought up on the mailinglist

files:
  pep-0414.txt |  38 ++++++++++++++++++++++++--------------
  1 files changed, 24 insertions(+), 14 deletions(-)


diff --git a/pep-0414.txt b/pep-0414.txt
--- a/pep-0414.txt
+++ b/pep-0414.txt
@@ -3,10 +3,11 @@
 Version: $Revision$
 Last-Modified: $Date$
 Author: Armin Ronacher <armin.ronacher at 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 @@
 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 @@
 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
-codebase is then used in Python 3, the interpreter will start using byte
-objects in places where they are no longer accepted (such as identifiers).
-This can be solved by a module that detects 2.x and 3.x and provides
-wrapper functions that transcode literals at runtime.  Unfortunately, this
-has the side effect of slowing down the runtime performance of Python and
-makes for less beautiful 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.
+available by syntax and has to be incorrectly labeled as bytestring.  If
+such a codebase is then used in Python 3, the interpreter will start using
+byte objects in places where they are no longer accepted (such as
+identifiers).  This can be solved by a module that detects 2.x and 3.x and
+provides wrapper functions that transcode literals at runtime (either by
+having a ``u`` function that marks things as unicode without future
+imports or the inverse by having a ``n`` function that marks strings as
+native).  Unfortunately, this has the side effect of slowing down the
+runtime performance of Python and makes for less beautiful 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 @@
 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
-    magnitude slower than the testsuite for the library or application
-    it's testing.
+-   Bad overall performance.  In many cases 2to3 runs 20 times slower than
+    the testsuite for the library or application it's testing.  (This for
+    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

-- 
Repository URL: http://hg.python.org/peps