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: [EMAIL PROTECTED]
Python forever!
-- http://mail.python.org/mailman/listinfo/python-list
