[omniORB] omniidl patch for Python backend

[David Fugate]

Hello, my name is David Fugate and I'm a developer for ALMA Common 
Software. For quite some time, we've run into a few problems with 
omniidl and the way it generates Python packages for IDL interfaces. It 
is a standard practice within my project to reopen IDL namespaces across 
different IDL files and then install the CORBA stubs into different 
areas of $PYTHONPATH. Doing this, we quite often end up being unable to 
import certain interface stubs as a (CORBA stub) package in one area of 
$PYTHONPATH overrides another one of the identical name.

As an all too brief example assume:
0. The beginning of your $PYTHONPATH looks like:
   "/A/lib/python/site-packages:/B/lib/python/site-packages:..."

1. You have a file named b.idl:
   module ALMA { interface B{}; };

This is compiled with omniidl and installed into:
   /B/lib/python/site-packages

producing:
   /B/lib/python/site-packages/ALMA/__init__.py (containing a single 
import for interface B)

2. You have an file named a.idl:
   module ALMA { interface A{}; };
This is compiled with omniidl and installed into:
   /A/lib/python/site-packages

producing:
   /A/lib/python/site-packages/ALMA/__init__.py (containing a single 
import for interface A)

3. From an interactive Python session you issue the commands:
   import ALMA
   ALMA.A
   ALMA.B #there will be an error issued by the interpreter because this 
cannot be found. /A/lib/python/site-packages/ALMA/__init__.py takes 
precedence over /B/lib/python/site-packages/ALMA/__init__.py

A modified version of the latest omniidl Python backend can be found at 
www.ras.ucalgary.ca/~dfugate/acs_python.py It takes into account the 
situation we have in ALMA and examines $PYTHONPATH when determining 
which imports go into __init__.py file. Please feel free to modify this 
file to adhere to any coding standards omniORB has and integrate it into 
omniidl. Really all that needs to be done is rename it to "python.py"

Sincerely,

David Fugate