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.
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.
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.
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.
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.
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.
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?
[+] [-] kibwen|14 years ago|reply
[+] [-] angersock|14 years ago|reply
yeah okay sure
(j/k nobody uses python 3)
[+] [-] z0ot|14 years ago|reply
[+] [-] andrewcooke|14 years ago|reply
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
[+] [-] sho_hn|14 years ago|reply
(I'll never figure out what the trick is.)
[+] [-] simonw|14 years ago|reply
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
[+] [-] njharman|14 years ago|reply
It is stupid to violate core values.
[+] [-] icebraining|14 years ago|reply
[+] [-] mixmastamyk|14 years ago|reply
[+] [-] batista|14 years ago|reply
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?
[+] [-] joeycfan|14 years ago|reply
[deleted]