Module/package hierarchy and its separation from file structure

[Steven D'Aprano]

On Tue, 29 Jan 2008 06:48:59 -0600, Peter Schuller wrote:

>> You can also put, in animal/__init__.py:
>>  from monkey import Monkey
>> and now you can refer to it as org.lib.animal.Monkey, but keep the
>> implementation of Monkey class and all related stuff into
>> .../animal/monkey.py
> 
> The problem is that we are now back to the identity problem. The class
> won't actually *BE* org.lib.animal.Monkey.

It what sense will it not be? Why do you care so much about where the 
source code for Monkey is defined? If you actually want to read the 
source, you might need to follow the chain from "animal", see that Monkey 
is imported from "monkey", and go look at that. But the rest of the time, 
why would you care?

There is a very good reason to care *in practice*: if there is code out 
there that assumes that the source code from Monkey is in the file it was 
found in. In practice, you might be stuck needing to work around that. 
But that's not a good reason to care *in principle*. In principle, the 
actual location of the source code should be an implementation detail of 
which we care nothing. It's possible that the source for Monkey doesn't 
exist *anywhere*.

It is important to deal with buggy tools. But the correct way to do so is 
to fix the bugs, not to throw away perfectly good abstractions.



-- 
Steven