Neil Schemenauer wrote: > Hi guys, > > With Guido's blessing, I just commited a change that takes a small step > towards where we want to be, IMO. Using __setattr__ on a module to > create a global name that shadows a builtin name now raises a > DeprecationWarning. E.g. > > import fileinput > fileinput.open = 10 # <- warning will be raised > > The goal is that the compiler should be able to determine the scope of a > name at compile time. Code like the above does not allow that and so > non-local names must be searched for in both globals and builtins at run > time. Spiffy. > Unfortunately the warning is not bulletproof. It's possible to > modify the module dict directly and bypass the warning. I'm not sure > what to do about that. :-( > Probably only way to deal with that would to come up with namespace dicts that can restrictions set on them? > Eventually we might want to allow optimizations based on known builtin > functions. For example, code like > > for i in range(100000): > ... > > could be rewritten to use an integer counter rather than creating a list > and then iterating over it. I'm not sure how much resistance there > would be in the community to disallowing reassignment of builtin names > though. I don't think I've ever reassigned a builtin name so I think it > would be worth it. > I am personally fine with this since I too never assign to built-in names, but I can see people raising a stink over this citing that their freedoms are being encroached upon. =) > The compiler could also warn about references to non-existent names. > That's a common error and would be helpful to developers. > Isn't this getting into PyChecker's territory? -Brett
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