On Saturday 01 February 2003 07:33 pm, Guido van Rossum wrote: ... > It is sort of against the rules of the language -- the whole point of > scoping is that you should be able to define variables even if they > block a builtin (that you may never have heard of and don't need) from > view. It would be wonderful to be able to OPTIONALLY get a warning for any "shadowing" of a name in an ``outer'' scope by a name in an ``inner'' scope, though -- I do (occasionally) miss Java's prohibition against doing that. > But it would be a great feature of PyChecker (for all I know, it > already does this). At least in 0.8.12, which I think is the current release, PyChecker doesn't diagnose the binding (in global or local scope) of built-in names with a warning, no. But I think you're right that such a functionality would belong there. > 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. 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. Alex
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