relative imports improve program organization... suggestions?

DG dangets at
Fri Aug 8 19:37:40 CEST 2008

Alright, I have searched and searched and read many conversations on
the topic of relative and absolute imports and am still not getting
the whole thing through my skull.

Highlights of what I've read:

So my problem and argument:
I want to create a package organized as the following:

The main program is located in and it implements the different
modules (A, B).  Within the modules the basic organization is; the
base class for all different types of A is directly within the moduleA
directory.  All of the different inherited classes of A are within
their own subdirectory with a mess of their own files.  This is done
so that a new subclass of A can be added/removed by just adding/
removing the subdirectory and each of these subclasses may have their
own maintainer, but they should all inherit from

If I am developing the A1 directory, I want to be able to test by using 'if __name__ == "__main__"' within the file and by typing 'python' on the command
line.  I prefer this simply to keep all unit tests within the same
directory and same file as the inherited class.

My Problem: has the line:
     'from ..A_base import A_Base_Class'
so that I can later declare the inherited class as such:

*BUT* I get the 'attempted relative import in non-package' error even
when I try the
'from __future__ import absolute_import' command.
I would prefer to be able to test the file without adding anything to
the PYTHONPATH, like I said by using the name == main trick.

So could someone explain to me what the rationale behind not allowing
parent directory relative imports is?  And possibly what I can do to
get around it?  (I really don't like messing with the sys.path for
something like this)

Danny G

More information about the Python-list mailing list