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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4