omniORB's CORBA module really lives in omniORB.CORBA, so you can doThat is what PyORBit is doing now too, with the exception that once you import one of the PyORBit modules, the modules named "CORBA" and "PortableServer" will point at the PyORBit versions.
"from omniORB import CORBA" instead of just "import CORBA". I believe Fnorb does the same thing, so it should be considered a de-facto standard. It would be good if pyorbit supported the same model.
The standard Python mapping says
"An IDL module is mapped into a Python module. Modules containing modules are mapped to packages (i.e., directories with an __init__ module containing all definitions excluding the nested modules). An implementation can chose to map toplevel definitions (including the module CORBA) to modules in an implementation defined package, to allow concurrent installations of different CORBA runtime libraries. In that case, the implementation must provide additional modules so that toplevel modules can be used without importing them from a package. "
So omniORB and Fnorb's behaviour is permitted if not exactly mandated.
Yep, and that seems to be a problem for distributors wishing to package multiple Python ORBs. I am not sure what the right choice here is.
The only issue for packagers is how to deal with the top-level CORBA
(and PortableServer, etc.) modules. One solution would be to install
them only if they are not already there from a different ORB.
James.
-- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
_______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
