[Python-Dev] PEP 414 - Unicode Literals for Python 3

[Vinay Sajip]

Nick Coghlan <ncoghlan <at> gmail.com> writes:

> 
> On Tue, Feb 28, 2012 at 10:10 PM, Vinay Sajip <vinay_sajip <at> yahoo.co.uk>
wrote:
> > If the 2.x code depends on having u'xxx' literals, then 3.2 testing will
> > potentially involve running a fixer on all files in the project every time a
> > change is made, writing to a separate directory, or else a fixer which is
> > integrated into the editing environment so it knows what changed. This is
> > painful, and what motivated PEP 314 in the first place - which seems ironic.
> 
> No, the real idea behind PEP 414 is that most ports that rely on it
> simply won't support 3.2 - they will only target 3.3+.

Well, yes in that the PEP will only be implemented in 3+, but the motivation was
to make a single codebase easier to achieve. It does that if you take the narrow
view of 2.6+/3.3+, but not if you factor 3.2 into the mix. Maybe 3.2 adoption is
too low for us to worry about here, but I for one certainly wish it hadn't been
relegated to being a 2nd-class citizen.

> The u"" fixer will just be one more tool in the arsenal of those that
> *do* want to support 3.2 (either because they want to target Ubuntu's
> LTS 3.2 stack, or for their own reasons). All of the other
> alternatives (such as separate branches or the unicode_literals future
> import) will also remain available to them.

Right, I get that - as I said, unicode_literals is my preferred path of the
options available. It's a shame to see this sort of Balkanisation, though. For
example, if Django retains u'xxx' literals (even though I've ported it using
unicode_literals, they may choose a different path officially), users wanting to
work with it using 2.6/2.7/3.2/3.3 (as I do now) are SOL as far as a single
codebase is concerned. Of course, when you're working on your own project, you
can call the shots. But problems can arise if you have to work with an external
project, as many of us frequently do.

Regards,

Vinay Sajip