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 know, don't feed the troll and all, but for the benefit of interested readers, here are two recent HN threads which largely discussed the current status of the migration:
TL;DR: The tone of such conversations has changed a lot since last year, IMHO. Python 3 is seeing real use now, those who made the switch seem to often be happy they did, and many who haven't yet can at least see the light at the end of the tunnel now. Generally there's a lot more optimism to be found.
Not only don't you need to change the code you shouldn't. This change has been introduced purely for code which tries to maintain Python 2 and Python 3 compatibility.
I don't want to be overly cynical, but a lot of users download the latest version, before they realize 2.7 is what they really want/need. I for one made that mistake. I know at least of a couple of friends who did this as well.
That is certainly a situation that happens, but I don't think the number of people who actually went on to install and use the interpreter for something is any significant amount lower.
DasIch is correct. This is meant to expedite the transition for those applications which have had trouble porting to python3 due to lack of developers or just difficulty in transitioning from use of unicode literals.
Tangent: If the 'reply' link below a comment is missing, please click the 'link' permalink to reply (you may need to wait a minute and reload it for the input box to appear). Please don't post replies as sibling comments as they won't necessarily appear in order.
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.
It's not so simple. As mentioned in the last paragraph, for example, Ubuntu LTS will release with Python 3.2. Backporting this feature to 3.2 will make it available to (updated and patched) Ubuntu LTS installs. NOT backporting this PEP could result in further delays in Python 3 adoption as people wait for Ubuntu 14.04 LTS.
A good point. I do wonder what proportion of Ubuntu users take advantage of the LTS releases rather than, say, just outright using Debian. I also intuitively want to say that anyone deciding to go with a LTS release would, if given the choice between a 2.7 library and a 3.2 library, choose the more "mature" option anyway.
I agree that it would have been smart to backport such a seemingly small and unobtrusive change to 3.2 (and who knows, maybe they still will).
Actually, no, after contemplation I realize that it would be much worse to split the compatibility of 3.2 and force library authors to qualify their compatibility targets by the minor version. After all, if the hypothetical 3.2.new didn't require any porting effort to support 3.3-style unicode literals, then library authors would have even less incentive to port their libraries to 3.2.old for all the people who can't upgrade, or won't upgrade, or who don't realize that their version doesn't feature a critical language addition.
in my experience, people (and distros) will update minor versions in mid-life patches/updates. so backporting gets this fix to "legacy" installs, where a new python version is not acceptable (i have clients with python 2.5 - 5 years from now the same kinds of people will be stuck on 3.1).
and i'm not sure why comparing three digits rather than two is so much more difficult. can you expand on your logic there?
> and i'm not sure why comparing three digits rather than two is so much more difficult. can you expand on your logic there?
Really only because it defies what people are used to. I really shouldn't have referred to that third number as the "minor version number", perhaps "the bugfix version number" would have been more appropriate, as that's what people (broadly speaking) expect it to stand for.
I acknowledge that there are arguments to be made for both viewpoints. However, I don't think that the risk of slightly delaying adoption of Python 3k due to concerns of a "compatibility hole" with Python 3.2 are worth introducing even more version chaos into the Python ecosystem. (You could just as easily argue that this move would prevent version chaos by eradicating the compatibility hole, but there will always those people who will forever be stuck on 3.2.old, for whatever reason.) I could be wrong! But regardless of what I think, the fact that the preceding argument can even be raised seems to indicate that it would be politically untenable for the Python devteam to suggest such a course of action. As far as they're concerned, Py3k adoption is progressing at a reasonable pace (though clearly not as smoothly as they'd hoped).
Modern stack is just not compatible with Ubuntu LTS. You can either pull stuffs from ppa, build them from source, roll your own packages, or, heaven forbid, choose a better distro.
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.
Good points, thanks. I intentionally lead with the name because to me, the news was which of the mocking libs around had been chosen for standard lib inclusion. But that limits the audience to those familiar with the field; your version works much better for a general interest audience indeed. I thought STL to be pretty common though.
No, the STL is the Standard Template Library, in C++, by STepanov and Lee at the HP Software Technology Laboratory. It doesn't mean "standard library", even though some inexperienced C++ programmers get confused between the STL and the rest of the standard library, now that the STL is part of the standard library.
STL is now a name for the C++ STandard Library, but it's semi backronymed. Originally, STL stood for "Standard Template Library", when it wasn't part of the C++ standard library.
So actually, STL refers to the standard library only in the context of C++, and only because of how it came to be.
Part of the trick is also not to give away too much in the title. If people want to know, which lib has been chosen, and they click on the link to find out, that does not have too be bad thing.
Sometimes I read a title, like let's say "X website reached Y amount of visitors". Even if I find that interesting, I won't click on the link, because the title already gives away all the information. Also I am not going to upvote it, if I have not even looked at the link.
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?
