At 12:22 PM 4/22/04 -0400, Jewett, Jim J wrote: >At 04:39 PM 4/21/04 -0400, Jewett, Jim J wrote: > >>>> If this is really only about globals and builtins, > >>>> then you can just initialize each module's dictionary > >>>> with a copy of builtins. > >(Note that Raymond's original proposal was much stronger; >instead of just moving builtins to globals, it moved both >builtins and globals into locals.) But at least it was still backward-compatible with respect to what actually is found in the module's globals. > >>Phillip J. Eby: > >>> There's only one problem with this idea, and it's a big > >>> one: 'import *' would now include all the builtins, > > >> Why is this bad? > > > Because some modules are examined by software, and only > > the expected names belong there. For example, I believe > > if you run 'pydoc' on such a module, it will proceed to > > document all the builtins. > >Fair enough. But that software could compare against >builtins, and do a set-minus. It *could*, but it's wasteful to break such programs without necessity. >But note that import * _already_ imports names which >shadow builtins, so the only real change would be when >the imported module does *not* shadow a builtin, but >your own module does (and does so before the import, >perhaps because of an earlier import *). > >If you want to protect even this obscure case, import >could be changed to special-case builtins. I think you're missing the part where builtins change from one release to the next. I might have had a global named 'zip' or 'enumerate' in a Python 1.5 program, and when I upgrade to 2.4 I am now "shadowing a builtin".
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