top | item 3714467

Python 3.3 reintroduces explicit Unicode literals to ease porting

89 points| kibwen | 14 years ago |python.org | reply

33 comments

order
[+] kibwen|14 years ago|reply
TL;DR: In Python 3.3, the string 'hello, world!' is synonymous with the string u'hello, world!' to more easily conform to the Python 2.X paradigm. It is not intended for use with new code. It is possible/expected that this feature will be deprecated and dropped in future releases of Python.
[+] angersock|14 years ago|reply
so we'll have to change our massive amount of python 3 code?

yeah okay sure

(j/k nobody uses python 3)

[+] z0ot|14 years ago|reply
from __past__ import unicode_literals
[+] andrewcooke|14 years ago|reply
this is great news, but will it be backported?

i had to jump through hoops to support 2+3 in a single code base because of this (in case people don't understand u"abc" is a syntax error in python 3.0-2, which makes writing portable code that uses unicode tricky, since that's what it a unicode literal looks like in python 2).

if it's not backported to 3.0-2 then we'll have the strange state of libraries that run on 2 and 3.3, but not inbetween.

[+] kibwen|14 years ago|reply
Won't be backported (which would be sort of weird in any case... if you were going to actually go to the trouble of upgrading your copy of 3.2 by a minor version, you might as well just upgrade to 3.3), but they do address this in the PEP:

  There are many existing Python communities that are prepared to put 
  up with the constraints imposed by the existing suite of porting 
  tools, or to update their Python 2 code bases sufficiently that the 
  problems are minimised.

  This PEP is not for those communities. Instead, it is designed 
  specifically to help people that don't want to put up with those 
  difficulties.

  However, since the proposal is for a comparatively small tweak to 
  the language syntax with no semantic changes, it is feasible to 
  support it as a third party import hook. While such an import hook 
  imposes some import time overhead, and requires additional steps 
  from each application that needs it to get the hook in place, it 
  allows applications that target Python 3.2 to use libraries and 
  frameworks that would otherwise only run on Python 3.3+ due to their 
  use of unicode literal prefixes.

  One such import hook project is Vinay Sajip's uprefix [4].

  For those that prefer to translate their code in advance rather than 
  converting on the fly at import time, Armin Ronacher is working on a 
  hook that runs at install time rather than during import [5].

  Combining the two approaches is of course also possible. For 
  example, the import hook could be used for rapid edit-test cycles 
  during local development, but the install hook for continuous 
  integration tasks and deployment on Python 3.2.

  The approaches described in this section may prove useful, for 
  example, for applications that wish to target Python 3 on the Ubuntu 
  12.04 LTS release, which will ship with Python 2.7 and 3.2 as 
  officially supported Python versions.
[+] sho_hn|14 years ago|reply
Michael Foord's mock lib also made it into the standard lib the other day, but I didn't manage to make the HN front page: http://news.ycombinator.com/item?id=3705923

(I'll never figure out what the trick is.)

[+] simonw|14 years ago|reply
A lot of it comes down to the title.

Your title was "Michael Foord's mock library added to Python 3.3 STL" - there are a couple of problems here. Firstly, most people won't know who Michael Foord is so using his name at the start of the title won't pull in any attention. Secondly, STL isn't a well known acronym for standard library.

Something like "Python standard library finally gains a mocking library in Python 3.3" might have worked better.

[+] takriz|14 years ago|reply
Sorry for this harsh statement, but Guido should do an internship at Theo of OpenBSD. We can't just decide to move backward to support programmers stupidity.
[+] njharman|14 years ago|reply
I like OpenBSD. But, Python is not OpenBSD, it has a different set of core values. Pragmatism being high up that list. It is written by and for pragmatic programmers. Not purists, not idealists.

It is stupid to violate core values.

[+] icebraining|14 years ago|reply
It doesn't actually move backward in any meaningful way, it just makes the parser ignore a (now) extraneous character.
[+] mixmastamyk|14 years ago|reply
It'll help porting which will get momentum moving behind v3.
[+] batista|14 years ago|reply
These Python programmers could potentially run circles in smartness around you or Theo. Or not. But it has nothing to do with the back-porting under discussion.

Not desiring to undertake a big code changing effort != stupidity.

Especially when you aren't even paid to do it.

Actually, considering that you would then have a patched mess of a codebase, or have to support to codebases for users of older Python versions, it's actually the smart thing to do.

And it's not like OpenBSD ever got anywhere --if you insist of using it as an example that "not moving backwards ever" is a plus. What's its adoption percentage again?