

Python 3.3 reintroduces explicit Unicode literals to ease porting - kibwen
http://www.python.org/dev/peps/pep-0414/

======
kibwen
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
so we'll have to change our massive amount of python 3 code?

yeah okay sure

(j/k nobody uses python 3)

~~~
sho_hn
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:

<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.

~~~
RayVR
Not to mention that Python3 has some awesome features, especially the
concurrent.futures module.

------
z0ot
from __past__ import unicode_literals

------
andrewcooke
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
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.

~~~
maaku
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.

~~~
kibwen
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).

~~~
kibwen
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.

~~~
andrewcooke
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?

~~~
kibwen

      > 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).

------
sho_hn
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
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.

~~~
sho_hn
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.

~~~
kragen
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.

------
takriz
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
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.

