Python 3.3 reintroduces explicit Unicode literals to ease porting
python.org
python.org
yeah okay sure
(j/k nobody uses python 3)
http://news.ycombinator.com/item?id=3696451
http://news.ycombinator.com/item?id=3666361
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.
Only about 450K downloads per month of Python 3 throughout 2011...on Windows, that platform no one uses.
[source: the first several slides of my PyCon talk - http://briancurtin.com/PyCon2012Presentation.pdf]
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.
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.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).
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?
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).
(I'll never figure out what the trick is.)
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.
So actually, STL refers to the standard library only in the context of C++, and only because of how it came to be.
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.
It is stupid to violate core values.
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?