Find the location of a loaded module

Steve Holden steve at holdenweb.com
Sun Feb 22 15:01:43 CET 2009


Gabriel Genellina wrote:
> En Sat, 21 Feb 2009 14:51:40 -0200, <rdmurray at bitdance.com> escribió:
> 
>> "Gabriel Genellina" <gagsl-py2 at yahoo.com.ar> wrote:
>>> En Fri, 20 Feb 2009 20:44:21 -0200, Aaron Scott
>>> <aaron.hildebrandt at gmail.com> escribi=F3:
>>>
>>> > So, the problem lies with how Python cached the modules in memory.
>>> > Yes, the modules were in two different locations and yes, the one that
>>> > I specified using its direct path should be the one loaded. The
>>> > problem is, the module isn't always loaded -- if it's already in
>>> > memory, it'll use that instead. And since the modules had the same
>>> > name, Python wouldn't distinguish between them, even though they
>>> > weren't exactly the same.
>>>
>>> Yes, that's how import works. It's barely documented, and you finally
>>> learned it the hard way...
>>
>> I'd argue a little bit with "barely documented".  In the reference, the
>> discussion of the import statement starts off saying:
>>
>>     Import statements are executed in two steps: (1) find a module,
>>     and initialize it if necessary; (2) define a name or names in the
>>     local namespace (of the scope where the import statement occurs).
>>
>> The third paragraph then says:
>>
>>     The system maintains a table of modules that have been or are being
>>     initialized, indexed by module name. This table is accessible as
>>     sys.modules. When a module name is found in this table, step (1)
>>     is finished.
>>
>> That is pretty up front and unambiguous documentation.
> 
> Sure? At a minimum, it doesn't define what "module name" means (isnt't
> so easy). It does not describe correctly how packages are handled, nor
> dotted names that aren't packages. It does not describe sys.meta_path
> nor sys.path_hooks, than can *radically* alter things. It does not
> describe absolute vs. relative imports, nor the "mix" of them in 2.x. It
> doesn't menction the *caller* module as relevant.
> 
>> However, the consequences of that statement won't be immediately clear
>> on first reading.  I think it would have cleared up Aaron's confusion
>> if he'd happened to think to read it.  But since he knew the syntax
>> of the import statement already, I'm not surprised he did not read it.
>>
>> The Tutorial, in the section on modules and import, says:
>>
>>     A module can contain executable statements as well as function
>>     definitions. These statements are intended to initialize the
>>     module. They are executed only the first time the module is imported
>>     somewhere.
>>
>> This is considerably less precise, if more superficially understandable.
>> I wonder if it would be worth expanding on that statement to mention
>> that the module is not even looked for on disk if a module by that
>> name has already been imported.
> 
> If only that were true... Importers can do almost anything they want.
> The behaviour you describe is only what happens when a) there are no
> meta_path hooks installed, b) there are no path_hooks involved, c)
> __import__ has not been replaced, and d) you are importing a module from
> the filesystem.
> 
> This is what I call "barely documented".
> 
Fortunately Brett Cannon has been working hard in this area, and we are
likely to see more straightforward import semantics in the near future.
In my own meanderings through the import system it did seem to me like
something that had grown organically into an arcane and impenetrable
system that was exceedingly difficult to understand.

regards
 Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/




More information about the Python-list mailing list