Module/package hierarchy and its separation from file structure

[Ben Finney]

Peter Schuller <peter.schuller at infidyne.com> writes:

> Let me just shoot down one possible suggestion right away, to show
> you what I am trying to accomplish:
> 
> 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.

Nevertheless, that seems the best (indeed, the Pythonic) solution to
your problem as stated. Rather than just shooting it down, we'll have
to know more about ehat actual problem you're trying to solve to
understand why this solution doesn't fit.

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

> Examples of way this breaks things:
> 
>   * X().__class__.__name__ gives unexpected results.

Who is expecting them otherwise, and why is that a problem?

>   * Automatically generated documentation will document using the
>   "real" package name.

Here I lose all track of what problem you're trying to solve. You want
the documentation to say exactly where the class "is" (by name), but
you don't want the class to actually be defined at that location? I
can't make sense of that, so probably I don't understand the
requirement.

-- 
 \        "If it ain't bust don't fix it is a very sound principle and |
  `\      remains so despite the fact that I have slavishly ignored it |
_o__)                                     all my life." —Douglas Adams |
Ben Finney