[omniORB] IDL stub topology in python

[Thomas Lockhart]

I've been looking at packaging for python IDL and have a few questions 
regarding the current behavior of omniidl. I'm hoping for some 
suggestions on how to install these into production areas.

Here is an example; questions follow:

   module x { module y { interface a {}; }; };

generates five files in four directories:

   a_idl.py
   x/
     __init__.py  - imports a_idl.py
     y/
       __init__.py  - imports a_idl.py
   x__POA/
     __init__.py  - imports a_idl.py
     y/
       __init__.py  - imports a_idl.py

Now, if I define in a separate file another interface in the same module 
namespace:

   module x { module y { interface b {}; }; };

I get these same files and one additional file b_idl.py at the top 
level. The other files are modified to import both a_idl.py and b_idl.py 
(pretty slick side-effect behavior from omniidl).

1) Why is a_idl.py (and b_idl.py) imported from all levels of the tree?

2) Why are a_idl.py and b_idl.py not isolated down into the appropriate 
subdirectories to avoid file name conflicts with other modules? Would it 
not be possible to import x.y.a_idl (and x.y.b_idl) and reduce the 
possibility of conflicts with, say,

   module m { module n { interface a {}; }; };

3) Generating stubs at the top level make it harder to build python 
packages (at least at my level of understanding). To get these _idl.py 
files included the top level directory has to contain a __init__.py and 
be mentioned explicitly as a module, since modules and individual .py 
files don't seem to coexist happily in a setup.py file. Or I have to 
include every file explicitly, which seems like a lot of work.

4) Why is the __POA tree built? Presumably it could allow separation of 
client code from server code.

Thanks in advance for feedback...

                     - Tom