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

More minor cleanups to PEP 414

This commit is contained in:
Nick Coghlan 2012-03-04 17:56:12 +10:00
parent 9f04df4927
commit 15ecef1316
1 changed files with 10 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
pep-0414.txt
View File

@ -221,8 +221,8 @@ three different kinds of string:
Native strings are a useful concept because there are some APIs and internal
operations that are designed primarily to work with native strings. They often
don't support ``unicode`` in Python 2 and don't support ``bytes`` in Python 3
(at least, not without needing additional encoding information and/or imposing
don't support ``unicode`` in Python 2 or support ``bytes`` in Python 3 (at
least, not without needing additional encoding information and/or imposing
constraints that don't apply to the native string variants).
Some example of such interfaces are:
@ -329,7 +329,7 @@ If the ``unicode_literals`` import approach is employed, but is not adopted
across the entire project at the same time, then the meaning of a bare string
literal may become annoyingly ambiguous. This problem can be particularly
pernicious for *aggregated* software, like a Django site - in such a situation,
some files may end up using the unicode literals import and others may not,
some files may end up using the ``unicode_literals`` import and others may not,
creating definite potential for confusion.
While these problems are clearly solvable at a technical level, they're a
@ -342,13 +342,15 @@ identified their Unicode strings in Python 2.
Armin Ronacher has created an experimental extension to 2to3 which only
modernizes Python code to the extent that it runs on Python 2.7 or later with
support from the cross-version compatibility ``six`` library is available as
``python-modernize`` [1]_. Currently, the deltas generated by this tool will
affect every Unicode literal in the converted source. This will create
legitimate concerns amongst upstream developers asked to accept such changes.
support from the cross-version compatibility ``six`` library. This tool is
available as ``python-modernize`` [1]_. Currently, the deltas generated by
this tool will affect every Unicode literal in the converted source. This
will create legitimate concerns amongst upstream developers asked to accept
such changes, and amongst framework *users* being asked to change their
applications.
However, by eliminating the noise from changes to the Unicode literal syntax,
many projects could be cleanly and (relatively) non-controversially made
many projects could be cleanly and (comparatively) non-controversially made
forward compatible with Python 3.3+ just by running ``python-modernize`` and
applying the recommended changes.