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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com