import statement - package visibility problem

[Laszlo Zsolt Nagy]

Here is the example:

http://designasign.biz/Lib2.zip

Please extract the file and try to import Lib2

Although \Lib2\Client\Db\DatabaseConnection.py and 
\Lib2\Server\Db\DatabaseConnection.py  have the same class name but they 
are in a different sub-package. From a programmer's view, I hope this is 
okay.

 >>> import Lib2
 >>> Lib2.Server.Db.Adapters.OracleConnection
<module 'Lib2.Server.Db.Adapters.OracleConnection' from 
'Lib2\Server\Db\Adapters\OracleConnection.pyc'>

As an example of my problem, please look inside OracleConnection. You 
will see that it imports DatabaseConnection with an absolute package name:

from Lib2.Client.Db.DatabaseConnection import DatabaseConnection

so the OracleConnection.py file is dependent of its location in the 
package tree. I would like to make it independent of the full package 
tree since it only depends on 'the upper level'. I could have 10 
different types of adapters and 3 drivers for each. This is not a 
special exampe, I would like to do the same with many other classes:

- SQLProcessor (with implementations connected directly to databases, 
logging to files, printing to stdout etc)
- ReportExporter (with implementations exporting reports to excel files, 
text files, CSV files, XML files, PDF files etc.)

You can think about others but with the same structure:

- Create  the abstraction level as the upper level package and
- not just separate the implementation by a new directory but also with 
a new namespace (new sub-package).

The advantages are clear:

- Keep the implementation level and the abstraction level in well 
separated namespaces
- Do not have redundacy in the code - every module can contain 
dependencies but only to other modules/packages that are really needed 
(for example, OracleConnection should not rely on the fact that the 'Db' 
package is inside the 'Server' package. It should not even rely on that 
the name of the containing package is 'Db'. Also it should not rely on 
that the 'Lib2' package on sys.path  etc.)
- As a result, you can move a sub-package to another location without 
the need to modify possibly hundreds of files
- As a result you can move the whole package tree to anywhere and import 
it without changes in your enviroment - this can lead to interesting 
uses as well

Are these advantages good enough to start developing a magic 
'__upperpackage__' variable?

This is my dream: assuming that the containing package is already 
imported to Python, this statement:

from __upperpackage__.DatabaseConnection import DatabaseConnection

would bind '__upperpackage__' to the containing package. Of course, if 
the containing package has not been imported yet then it would raise an 
exception (ImportError: no module named __upperpackage__).

What do you think?

-- 
_________________________________________________________________
  Laszlo Nagy		      web: http://designasign.biz
  IT Consultant		      mail: gandalf at geochemsource.com

     		Python forever!