Python-list Digest, Vol 76, Issue 97

[Mitchell L Model]

On Jan 8, 2010, at 7:35:39 PM EST, Terry Reedy <tjreedy at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20100109/b898fc46/attachment.html>