Module import information
eswhite at gmail.com
Tue Mar 21 22:12:12 CET 2006
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 <steve at holdenweb.com> 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
> > 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
> 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
> 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?
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-list