Module/package hierarchy and its separation from file structure

[Carl Banks]

On Jan 23, 4:49 am, Peter Schuller <peter.schul... at infidyne.com>
wrote:
> 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. Examples of way this breaks things:
>
>   * X().__class__.__name__ gives unexpected results.
>   * Automatically generated documentation will document using the "real"
>     package name.
>   * Moving the *actual* classes around by way of this aliasing would
>     break things like pickled data structure as a result of the change
>     of actual identity, unless one *always* pre-emptively maintains
>     this shadow hierarchy (which is a problem in and of itself).


You can reassign the class's module:

from org.lib.animal.monkey import Monkey
Monkey.__module__ = 'org.lib.animal'


(Which, I must admit, is not a bad idea in some cases.)


Carl Banks