Jim J. Jewett wrote: > > http://mail.python.org/pipermail/python-dev/2012-March/117395.html > Brett Cannon posted: > > [in reply to Mark Shannon's suggestion of adding a builtins parameter > to match locals and globals] > >> It's a mess right now to try to grab the __import__() >> implementation and this would actually help clarify import semantics by >> saying that __import__() for any chained imports comes from __import__()s >> locals, globals, or builtins arguments (in that order) or from the builtins >> module itself (i.e. tstate->builtins). > > How does that differ from today? The idea is that you can change, presumable restrict, the builtins separately from the globals for an import. > > If you're saying that the locals and (module-level) globals aren't > always checked in order, then that is a semantic change. Probably > a good change, but still a change -- and it can be made indepenently > of Mark's suggestion. > > Also note that I would assume this was for sandboxing, Actually, I just think it's a cleaner implementation, but sandboxing is a good excuse :) > and that > missing names should *not* fall back to the "real" globals, although > I would understand if bootstrapping required the import statement to > get special treatment. > > > (Note that I like Mark's proposed change; I just don't see how it > cleans up import.) I don't think it cleans up import, but I'll defer to Brett on that. I've included __import__() along with exec and eval as it is a place where new namespaces can be introduced into an execution. There may be others I haven't though of. Cheers, Mark.
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