> > There's one situation where I actually *do* think this is worth a > > warning, or perhaps even an error. When you import a module and > > assign to an attribute of it that didn't exist before and has the name > > of a built-in, you may change that module's meaning. If this wasn't > > Very good point. Such behavior seems unlikely to me to be > accidental (the usage "import X; X.Y=Z" is rare indeed), so I'm > not sure warnings would help all that much -- but, _forbidding_ > this when Y names a built-in could indeed open the way to some > very useful optimizations in the future. Exactly. > Of course, enabling this optimization would also require a > prohibition against "overriding" of built-ins by one's own versions > -- I don't think that would be a great loss in terms of practical > functionality. There are very few builtins for which overriding is useful in practice. The only ones for which it is are __import__ (which was designed with this in mind!) or open and file, which one might want to replace with versions that do access checking in a restricted execution environment. I think we could make this list explicit. People who override built-ins with versions they wrote themselves that have different (extended) semantics are crazy. People who add their own functions to __builtin__ are lazy. Neither deserves support. :-) BTW, Alex, will you be at PyCon? If not, will you be at Python UK the next week? If not, at EuroPython? --Guido van Rossum (home page: http://www.python.org/~guido/)
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