Module/package hierarchy and its separation from file structure

[Carl Banks]

On Jan 29, 7:48 am, Peter Schuller <peter.schul... at infidyne.com>
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.

The usage is the same; it works in all cases once you redefine
__module__.  Who cares what it really is?


> Perhaps manipulating
> __module__ is enough; perhaps not (for example, what about
> sys.modules?).

It's enough.  It satisfies the criteria you listed. sys.modules has
nothing to do with it.  Monkey is a class, not a module.

If you set __module__, the only remaining discernable difference is
that the global variables accessed from the Monkey class will be in
org.lib.animal.monkey instead of org.lib.animal.  This has no ill
effects when unpickling or instantiating the class from
org.lib.animal.

> Looks like I'll just live with putting more than I
> would like in the same file.

Whatever.  ISTM you came here looking for a particular means and not a
particular end.  Python already has the power to meet your stated
needs, but you won't use that solution because it's "hacky".
Apparently all you really wanted was the loosened file structure in
the first place.


Carl Banks