iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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

This commit is contained in:
Armin Ronacher 2012-02-28 08:18:52 +00:00
parent 0588c41b39
commit 5a2d803bbd
1 changed files with 24 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
pep-0414.txt
View File

@ -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
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 @@ 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
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