On Jan 8, 2010, at 7:35:39 PM EST, Terry Reedy <tjre...@udel.edu> wrote:
On 1/8/2010 12:02 PM, Mitchell L Model wrote:
On further reflection, I will add that
what appears to be happening is that during import both the global
and
local dictionaries are set to a copy of the globals() from the
importing
scope and that copy becomes the value of the module's __dict__ once
import has completed successfully.
I have no idea why you think that. The module dict starts empty
except for __name__, __file__, and perhaps a couple of other
'hidden' items. It is not a copy and has nothing to do with
importing scopes.
Why I think -- or, rather, thought -- that was because of some
defective experiments I ran. It was purely a delusion. Thank you for
correcting it.
> and that copy becomes the value of the module's __dict__ once
> import has completed successfully.
That new dict becomes .... .
Because exec leaves locals() and globals() distinct,
Not necessarily.
In 3.x, at least,
exec(s)
executes s in the current scope. If this is top level, where locals
is globals, then same should be true within exec.
Yes. To simplify some of my ramblings and incorporate the points you
and others have made, and to once again acknowledge Python's elegance,
an important observation which I bet even a lot of serious Python
programs don't realize (or at least not consciously) is that:
globals() is locals()
in the following contexts:
the interpreter top level
the top level of a module (though as you point out, starts out as a
very bare dictionary during import)
a string being exec'd when the call to exec includes
no dictionary argument(s)
one dictionary argument
the same dictionary as both the second and third arguments
The identity does not hold for:
a string being exec'd when a different dictionary is provided as the
second and third arguments to exec
inside anything that creates a scope: a function definition, class
definition, etc.
Did I get all that right? Are there any other contexts that should be
included in these?
d = {}
exec(s, d)
In 3.x, at least, d will also be used as locals.
Yes, talking about 3.x.
exec(s, d, d)
Again, globals and locals are not distinct.
It would seem that in 3.x, the only way for exec to have distinct
globals and locals is to call exec(s) where they are distinct or to
pass distince globals and locals.
Apparently so. To clarify "where they are distinct", that would mean
from a context in which they were already distinct, which is not the
case if exec is called from the top level, but is the case if called
from within, say, a function, as my code does.
Some of the issues of this thread are discussed in Language
Reference 4.1, Naming and Binding. I suppose it could be clearer
that it is, but the addition of nonlocal scope complicated things.
I pretty much have that section memorized and reread it at least
monthly. It's part of what I meant by starting my original comments by
saying that I thought I understood all of this. Thank you (and others)
for helping clarify exactly what's going on. As with so many things in
Python, it is not always easy to keep one's preconceptions, delusions,
and experiences with other languages out of the way of its simplicity,
even if one is a very experienced and knowledgeable Python programmer.
--- Mitchell--
http://mail.python.org/mailman/listinfo/python-list
