Module/package hierarchy and its separation from file structure

[Gabriel Genellina]

En Thu, 24 Jan 2008 05:16:51 -0200, Peter Schuller  
<peter.schuller at infidyne.com> escribió:

>>> I do *not* want to simply break out X into org.lib.animal.x, and
>>> have org.lib.animal import org.lib.animal.x.X as X.
>>
>>> While this naively solves the problem of being able to refer to X as
>>> org.lib.animal.X, the solution is anything but consistent because
>>> the *identity* of X is still org.lib.animal.x.X.
>>
>> The term "identity" in Python means something separate from this
>> concept; you seem to mean "the name of X".
>
> Not necessarily. In part it is the name, in that __name__ will be
> different. But to the extent that calling code can potentially import
> them under differents names, it's identity. Because importing the same
> module under two names results in two distinct modules (two distinct
> module objects) that have no realation with each other. So for
> example, if a module has a single global protected by a mutex, there
> are suddenly two copies of that. In short: identity matters.

That's not true. It doesn't matter if you Import  a module several times  
at different places and with different names, it's always the same module  
object.

py> from xml.etree import ElementTree
py> import xml.etree.ElementTree as ET2
py> import xml.etree
py> ET3 = getattr(xml.etree, 'ElementTree')
py> ElementTree is ET2
True
py> ET2 is ET3
True

Ok, there is one exception: the main script is loaded as __main__, but if  
you import it using its own file name, you get a duplicate module.
You could confuse Python adding a package root to sys.path and doing  
imports from inside that package and from the outside with different  
names, but... just don't do that!

> I realize that technically Python does not have this either. Like I
> said in the original post, I do realize that I can override __import__
> with any arbitrary function, and/or do magic in __init__. But I also
> did not want to resort to hacks, and would prefer that there be some
> kind of well-established solution to the problem.

I don't really understand what your problem is exactly, but I think you  
don't require any __import__ magic or arcane hacks. Perhaps the __path__  
package attribute may be useful to you. You can add arbitrary directories  
to this list, which are searched for submodules of the package. This way  
you can (partially) decouple the file structure from the logical package  
structure. But I don't think it's a good thing...

> in Java, you would have the class
>
>    org.lib.animal.Monkey
>
> in
>
>    <wherever>/org/lib/animal/Monkey.java
>
> and
>
>    org.lib.animal.Tiger
>
> in
>
>    <wherever>/org/lib/animal/Tiger.java
>
> In other words, introducing a separate file does not introduce a new
> package. This works well as long as you are fine with having
> everything related to a class in the same file.
>
> The problem is that with Python, everything is not a classes, and a
> file translates to a module, not a class. So you cannot have your
> source in different files without introducing as many packages as you
> introduce files.

Isn't org.lib.animal a package, reflected as a directory on disk? That's  
the same both for Java and Python. Monkey.py and Tiger.py would be modules  
inside that directory, just like Monkey.java and Tiger.java. Aren't the  
same thing?

-- 
Gabriel Genellina