Cross-reference 'import' in a class hierarchy

[Jeremy Bowers]

On Mon, 07 Apr 2003 01:06:06 +0000, Ben Finney wrote:
> These aren't in a state to be site packages; they're still undergoing
> rapid architectural changes.  Thus, using monthy.pth isn't an option
> (unless you can tell me otherwise).
> 
> Any guidance appreciated as I tread this unfamiliar ground.

Good luck; I asked this question a while ago and the consensus is,
depending on your point of view, "why the hell would you want to do that?"
or "can't be done".

It is interesting that all the Python programs I've seen that are broken
up into files at all (and not just 100+KB hunks of text) are plopped into
one directory.  

IMHO, this is the largest wart by far in Python when it comes to writing
"real" programs that really shouldn't have every file dumped into the same
directory. I also find the solution of putting references to the
application in the Python directory or the other standard solutions
completely unsatisfactory. It's one thing for a library to go live in "the
main namespace", it's quite another for my application to do so; this is
apparently the one namespace in Python that it is *acceptable* to pollute.

For instance, my application has a file in the top-level named "gui.py",
named that for the very good reason that it switches between the (currently)
2 GUI frameworks the program supports. Is it so inconceivable that
some other application might want to use that name too without conflict?

Applications aren't libraries and there should be somewhat better support
for this sort of thing. On the simplest level, one could rise up the
directories until one either hits root or some token file that says "Here,
I'm an application!" and use that as the first dir in the search path.

I'd PEP it but given that nobody else is uncomfortable polluting this part
of the namespace it seems the odds of it going anywhere are slim.

In the meantime, I've made do with the following boilerplate, dropped as
needed in files as I'm going:

import sys
import os
if __name__ != "__main__": # add parent dir to path
    f = __file__
    f = os.path.normpath(os.path.dirname(f) + os.sep + os.pardir)
    if f not in sys.path: sys.path.append(f)                     
else:
    sys.path.append("..")

Repeat the lines as appropriate to add the grandparent, etc. depending on
how deep the file is. 'import something_at_the_root_of_the_app' will then
work as you expect, provided there aren't any name conflicts with
libraries or internal to your app. Those do get hard to manage; I named a
package "commands" without realizing that is actually an obscure Python std
lib package. Note that as the Python library grows, along with the
popularity of certain almost-standard libraries like PIL, this sort of
thing is going to happen more often...

In particular, I have found this helpful in putting all the unit tests in
separate directories named "tests" under the things they are actually
testing, as this allows the test modules to directly import the things
they are testing, regardless of whether they've been packaged or are
available from the bare "import" command, without polluting the directory
itself with more files. (It's bad enough as it is with as much as a .py, a
.pyc, a #.py#, and a .py~ for each Python file when using emacs to write
Python.)