On Sun, Feb 26, 2012 at 7:05 PM, Vinay Sajip <vinay_sajip@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@gmail.com | Brisbane, Australia