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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
