GeezerVison

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

> 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

I didn't meaning the __future__ import bit, but a discussion re. alternatives to
u('xxx').

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

I don't disagree with anything you said here. Perhaps I've been doing too much
work recently with single 2.x/3.x codebase projects, so I've just gotten to like
using Unicode literals without the u prefix. However, as the proposal doesn't
force one to use u prefixes, I'm not really objecting, especially if it speeds
transition to 3.x.

Regards,

Vinay Sajip