I'm tending towards believing that it would be best to pass the globals
and locals to the designated __import__ function (along with the module
name), and then let the function take care of the module name binding. (In
fact, my code does this by using that cute function i've mentioned to you,
which determines the binding dicts of the caller's scope by triggering and
catching an exception, and then unravelling the traceback stack).
Eg:
def import_module(name, locals, globals): ...
(and '__import__ = import_module')
Furthermore, i am thinking there could be one additional, optional
parameter, 'froms'. It would take an array of strings (or None, by
default) naming the definitions that are to be bound in the calling scope.
Eg:
def import_module(name, locals, globals, froms=None): ...
The __import__ function would be responsible for imposing the proper
bindings, including accounting for things like 'from blat import *'.
Does this sound ok? If you are willing, and could make it available to me
sometime soon, i should be able to have the prototype clean and fully
operational within a week or so. (Incidentally, among many other more
work-related things, i am also currently busy laying out the groundwork
for setting up a server as the python.org host...)
Of course, the form of what i've implemented has changed a bit from what
we discussed.
So far, it looks like the best way to denote importation of modules
within a package by other modules within the same package is by
explicitly prepending a '.' to the module name:
import .sibling
Sort of like a Unix symbolic links refer to relative paths in the same
directory using './'.
Among other things, this enables a package module to directly contain all
the definitions of its' component modules by having a __main__ module that
does:
from . import *
Is this clear? I've written up a little synopsis of the usage modes and
benefits, currently among the comments for the newimp module, but i figure
it's longer that you would want to read right now. (I expect that this is
longer than you want to read right now, but i know of no other way to
proceed, at the moment.-)
One last item. I posted something proposing having the absolute path of a
module be associated with the module, as a __path__ atribute. (The
purpose is so 'reload()' would get the module from the original place,
rather than re-scanning the path and possibly finding a different module,
if eg the cwd is different.) I never saw a response from you, and thought
you may have let it slide and then forgotten about it. However, i am
planning on implementing it in my code, and am wondering if you see any
reason to not do so.
One person responded, saying that it seemed like a good idea, but perhaps
some supported os doesn't provide for determination of an absolute path
for any loaded module. Do you know the situation there?
i hope things are going well there, ...?
ken