Module/package hierarchy and its separation from file structure

[Peter Schuller]

>> 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.

Sorry, this is all my stupidity. I was being daft. When I said
importing under different names, I meant exactly that. As in, applying
hacks to import a module under a different name by doing it relative
to a different root directory. This is however not what anyone is
suggesting in this discussion. I got my wires crossed. I fully
understand that "import x.y.z" or "import x.y.z as B", and so one do
not affect the identity of the module.

> 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!

Right :)

> 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...

That sounds useful if I want to essentially put the contents of a
directory somewhere else, without using a symlink. In this case my
problem is more related to the "file == module" and "directory ==
module" semantics, since I want to break contents in a single module
out into several 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?

No, because in Java Monkey.java is a class. So we have class Monkey in
package org.lib.animal. In Python we would have class Monkey in module
org.lib.animal.monkey, which is redundant and does not reflect the
intended hierarchy. I have to either live with this, or put Monkey in
.../animal/__init__.py. Neither option is what I would want, ideally.

Java does still suffer from the same problem since it forces "class ==
file" (well, "public class == file"). However it is less of a problem
since you tend to want to keep a single class in a single file, while
I have a lot more incentive to split up a module into different files
(because you may have a lot of code hiding behind the public interface
of a module).

So essentially, Java and Python have the same problem, but certain
aspects of Java happens to mitigate the effects of it. Languages like
Ruby do not have the problem at all, because the relationship between
files and modules is non-existent.

-- 
/ Peter Schuller

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller at infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey at scode.org
E-Mail: peter.schuller at infidyne.com Web: http://www.scode.org