Module import information

[Eric White]

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
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20060321/97967977/attachment.html>