<from my readme> ....concerning the specification of the Python-SAGA language binding. The result will be a Python specification which is independent of the SAGA reference implementation
Good!
A user program imports saga.py. In saga.py an environment variable is extracted (SAGA_IMPLEMENTATION_NAME, not decided on final name), and saga.py uses this name to import the various implementation specific python modules. In my case the SAGA_IMPLEMENTATION_NAME is defined as sagajavaLB (still no final name) and in module sagajavaLB, the python files with the java specific code are imported.
By each time using 'from <name> import <class>' the user can use the classes like saga.file.File() instead of saga.sagajavaLB.sagaFile.File() Using this, the user could switch language binding implementation (python-to-java of python-to-cpp) by changing the environment variable.
In the cpp case, a sagacppLB.py could be added, which imports, (maybe even maps functions to existing functions), and calls the already defined python wrapper.
This seems an unnecessary complication - why not just change the PYTHONPATH to change implementation. I like the way the email package is structured into modules. You import what you need and you don't have strange things going on behind your back - potentially polluting your namespace. Steve