On 2/26/2012 6:14 AM, Nick Coghlan wrote: > 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. There are already __future__ imports that violate this principle: from __future__ import division. That doesn't mean I'm in favor of this new __future__, just keeping a wide angle on the viewfinder. --Ned.
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