[Python-Dev] PEP 414

[Nick Coghlan]

On Sun, Feb 26, 2012 at 7:05 PM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
> The PEP does not consider an alternative idea such as using "from __future__
> import unicode_literals" in code which needs to run on 2.x, together with e.g. a
> callable n('xxx') which can be used where native strings are needed. This avoids
> the need to reintroduce the u'xxx' literal syntax, makes it explicit where
> native strings are needed, is less obtrusive that u('xxx') or u'xxx' because
> typically there will be vastly fewer places where you need native strings, and
> is unlikely to impose a major runtime penalty when compared with u('xxx')
> (again, because of the lower frequency of occurrence).
>
> Even if you have arguments against this idea, I think it's at least worth
> mentioning in the PEP with any counter-arguments you have.

The PEP already mentions that. In fact, all bar the first paragraph in
the "Rationale and Goals" section discusses it. However, it's the last
paragraph that explains why using that particular future import is, in
and of itself, a bad idea:

============
Additionally, the vast majority of people who maintain Python 2.x
codebases are more familiar with Python 2.x semantics, and a per-file
difference in literal meanings will be very annoying for them in the
long run. A quick poll on Twitter about the use of the division future
import supported my suspicions that people opt out of
behaviour-changing future imports because they are a maintenance
burden. Every time you review code you have to check the top of the
file to see if the behaviour was changed. Obviously that was an
unscientific informal poll, but it might be something worth
considering.
============

As soon as you allow the use of "from __future__ import
unicode_literals" or a module level "__metaclass__ = type", you can't
review diffs in isolation any more - whether the diff is correct or
not will depend on the presence or absence of module level tweak to
the language semantics.

Future imports work well for things like absolute imports, new
keywords, or statements becoming functions - if the future import is
missing when you expected it to be present (or vice-versa) will result
in a quick SyntaxError or ImportError that will point you directly to
the offending code. Unicode literals and implicitly creating new-style
classes are a different matter - for those, if the module level
modification takes place (or doesn't take place when you expected it
to be there), you get unexpected changes in behaviour instead of a
clear exception that refers directly to the source of the problem.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia