Repost: execfile() confusion

[Nathaniel Gray]

Tim Peters wrote:

> [Nathaniel Gray, being unreasonable <wink>]

Perhaps you didn't realize that I posted this message *before* I read your 
other reply, which immediately cleared things up.  <deflects wink>

>> ...
>> Here's a slightly modified version of the files that
>> will perhaps make my confusion clear:
> 
> Except there's no point to clearing it up:  you're chasing accidents, and
> even if you figure out why they're happening, they may change in the next
> release.  I added this text to the library ref man earlier today, under the
> execfile() docs:
> 
>   \strong{Warning:} The default \var{locals} act as described for function
>   \function{locals()} below:  modifications to the default \var{locals}
>   dictionary should not be attempted.  Pass an explicit \var{locals}
>   dictionary if you need to see effects of the code on \var{locals} after
>   function \function{execfile()} returns.  \function{execfile()} cannot
>   be used reliably to modify a function's locals.

I'm glad to see this.  It would have saved me a lot of confusion.

> Spend a tenth of this energy thinking of a clean way to do
> whatever it is you're after, and you could enjoy life again.

Considering that what I was after was an understanding of why a seemingly 
straightforward builtin function was acting deeply weird, I felt that posting 
to c.l.p *was* the "clean" way to do it.  ;-)  And who said I ever enjoyed life 
in the first place??

> Most parts of the local/global behavior are the same; other parts have
> changed; what's changed the most is all the text added to the docs telling
> people to stop doing things that Guido never believed anyone in their right
> mind would even attempt <wink>.

You seem to think I'm totally off my rocker.  That may be true, but my question 
was sparked by a perfectly reasonable scenario, by any reasonable definition 
of "reasonable".  ;^)

I think it would be nice to use Python statements in my configuration files for 
various Python projects.  I don't think it would be nice to put said 
configuration files on my pythonpath--they're not python modules like 
'gracePlot.py', they're configuration files like 'gizmos.config'.  I want to do 
"from 'path/to/gizmos.config' import *" (don't suppose it's worth asking for 
this syntax to become legal?), but all I really want is to have gizmos.config 
run through the interpreter and then have access to the variables it defines 
(i.e. I don't care about having a real module object).  I also obviously need 
to be able to specify the location of gizmos.config since I don't want to have 
to care whether or not my configuration file ends with '.py', lives on the 
pythonpath, or has a name that conflicts with some random module somewhere.

Thinking about these requirements, a fuzzy memory springs to mind--isn't there 
a way to execute python code from some given file?  Looking at the ref man's 
docs for execfile it looks like just the thing!  Hooray!  But then I happen to 
use this scheme within a function and bizarre things happen.  Boo!  :-(

Anyhow, lest there be any further confusion:  there is no further confusion!  I 
just wanted to know if I was witnessing well understood behavior or if I'd 
found a bug in Python.  Now I understand that there *are* no bugs in Python, 
just implementation quirks that, much like UFOs, are only visible to 
malcontents, the mentally unbalanced, and grad students.  (Not mutually 
exclusive groups by any stretch of the imagination.)

> execfile-is-to-exec-as-delicious-is-to-del-ly y'rs  - tim

and-as-unichristalmighty!-is-to-unichr-ly y'rs - n8

-- 
Nathaniel Gray

California Institute of Technology
Computation and Neural Systems
--