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.

On 3/21/06, Steve Holden <[EMAIL PROTECTED]> wrote:
Eric White wrote:
> Peter:
>
> Thanks for the reply.  Consider the following situation:
>
> A set of variable names is defined along with a list of possible values
> for each.   A second set of variable names is defined along with an
> _expression_ for generating a value for each.  For each possible
> permutation of variables from the first set, a python script is created
> that contains commands that initialize the variable set with the
> permuted values.  A second python script is created that contains
> commands for connecting to a database and storing the values of the
> second set of variables after running the associated _expression_ for each.
>
> We would like to be able to use the scripts above to drive a python
> script containing a system of equations specified at run time and to
> store the results.  This "master" script contains the following calls:
>
> import somemodule
>
> # do stuff ...
>
> # initialize permuted variables
> somemodule.init()
>
> # do more stuff ...
>
> # store results
> somemodule.save ()
>
> # do more stuff ... Etc.
>
> We would like for the call to init to initialize variables in the
> context of the "master" script.  To do this inside somemodule we use the
> sys.modules dictionary to find a reference to the master module by name
> and initialize variables at this reference.
>
> What I would like to know if it is arbitrarily possible to "walk" the
> import hierarchy from any point.  It is not apparent that python's
> optimization of subsequent imports of the same module is relavent.
>
It seems to me that you could achieve the same end by accessing the
calling stack frame inside the calls to your somemodule.functions().
Whether this is acceptable or not (and whether you are prepared to put
up with the necessary voodoo) is another question.

However, this would lead to atrocious coupling in your program. It's the
kind of thing people used to use Fortran common blocks for, for goodness
sake!

The point Peter was trying to make about the distinction between first
import of a module and subsequent ones is, I suspect, quite relevant, as
you made it appear that you wanted to rely on code executed *during the
import* to distinguish its importer. Clearly this would only be possible
on the first import, as subsequent imports wouldn't execute the module's
code.

But now it appears that the import structure isn't really as relevant as
the calling relationships anyway, no?

Or am I misunderstanding your intent?

regards
  Steve

--
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd                 www.holdenweb.com
Love me, love my blog         holdenweb.blogspot.com

--
http://mail.python.org/mailman/listinfo/python-list

-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to