[Python-Dev] PEP 414 - Unicode Literals for Python 3 (original) (raw)

Vinay Sajip vinay_sajip at yahoo.co.uk
Tue Feb 28 14:02:18 CET 2012


Nick Coghlan <ncoghlan gmail.com> writes:

On Tue, Feb 28, 2012 at 10:10 PM, Vinay Sajip <vinaysajip 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 unicodeliterals 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



More information about the Python-Dev mailing list