I found a builtin function called "execfile" that seems to suite my
needs quite well.  The import function is less applicable. 
Thanks for your time.<br><br><div><span class="gmail_quote">On 3/21/06, <b class="gmail_sendername">Steve Holden</b> <<a href="mailto:steve@holdenweb.com">steve@holdenweb.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Eric White wrote:<br>> Peter:<br>><br>> Thanks for the reply.  Consider the following situation:<br>><br>> A set of variable names is defined along with a list of possible values<br>> for each.   A second set of variable names is defined along with an
<br>> expression for generating a value for each.  For each possible<br>> permutation of variables from the first set, a python script is created<br>> that contains commands that initialize the variable set with the
<br>> permuted values.  A second python script is created that contains<br>> commands for connecting to a database and storing the values of the<br>> second set of variables after running the associated expression for each.
<br>><br>> We would like to be able to use the scripts above to drive a python<br>> script containing a system of equations specified at run time and to<br>> store the results.  This "master" script contains the following calls:
<br>><br>> import somemodule<br>><br>> # do stuff ...<br>><br>> # initialize permuted variables<br>> somemodule.init()<br>><br>> # do more stuff ...<br>><br>> # store results<br>> somemodule.save
()<br>><br>> # do more stuff ... Etc.<br>><br>> We would like for the call to init to initialize variables in the<br>> context of the "master" script.  To do this inside somemodule we use the<br>> 
sys.modules dictionary to find a reference to the master module by name<br>> and initialize variables at this reference.<br>><br>> What I would like to know if it is arbitrarily possible to "walk" the<br>
> import hierarchy from any point.  It is not apparent that python's<br>> optimization of subsequent imports of the same module is relavent.<br>><br>It seems to me that you could achieve the same end by accessing the
<br>calling stack frame inside the calls to your somemodule.functions().<br>Whether this is acceptable or not (and whether you are prepared to put<br>up with the necessary voodoo) is another question.<br><br>However, this would lead to atrocious coupling in your program. It's the
<br>kind of thing people used to use Fortran common blocks for, for goodness<br>sake!<br><br>The point Peter was trying to make about the distinction between first<br>import of a module and subsequent ones is, I suspect, quite relevant, as
<br>you made it appear that you wanted to rely on code executed *during the<br>import* to distinguish its importer. Clearly this would only be possible<br>on the first import, as subsequent imports wouldn't execute the module's
<br>code.<br><br>But now it appears that the import structure isn't really as relevant as<br>the calling relationships anyway, no?<br><br>Or am I misunderstanding your intent?<br><br>regards<br>  Steve<br><br>--<br>Steve Holden       +44 150 684 7255  +1 800 494 3119
<br>Holden
Web
LLC/Ltd                
<a href="http://www.holdenweb.com">www.holdenweb.com</a><br>Love me, love my blog         <a href="http://holdenweb.blogspot.com">holdenweb.blogspot.com</a><br><br>--<br><a href="http://mail.python.org/mailman/listinfo/python-list">
http://mail.python.org/mailman/listinfo/python-list</a><br></blockquote></div><br>