Re: [Orbit-python-list] Uploaded patch

[Duncan G. <dg...@uk...>]

> > The mapping standard says that it must be possible to do just "import
> > CORBA", and get the default CORBA installation, so with compliant ORBs
> 
> I suppose that means installing a new ORB will clobber the existing CORBA
> module?  

Yes, to the extent that "import CORBA" will now get the new ORB. If
all the ORBs stick to the "from foo import CORBA" practice, and use a
wrapper module to support "import CORBA", all installed ORBs will
still be available for programs which care.

> > you do not need to change any code at all. This is one aspect of the
> > Python mapping which caused headaches for me with omniORBpy, since
> > it's geared towards the "from omniORB import CORBA" style. I have to
> 
> What headaches has it caused?  Why wouldn't just a simple wrapper to import
> omniORB.CORBA work?

Maybe "headache" is too strong a word. It isn't a good idea for
CORBA.py to just say "from omniORB.CORBA import *", firstly because
omniORB.CORBA contains some important items prefixed with underscores,
which do not get imported with import *. Secondly, that approach
wastes memory since it fills a second dictionary with the names of the
module's contents.

omniORBpy's CORBA.py actually looks like

  import sys, omniORB.CORBA
  sys.modules["CORBA"] = omniORB.CORBA

which is a bit of a dirty hack. It's a module which replaces itself
while it's still being imported.

> Anyway, it may be worth it for me to post these issues to comp.lang.python
> and spark a discussion.  I'm humble enough to take advice from people who
> know much more than I do. :)

Maybe. It might be better to discuss it in do...@py....
Unfortunately, now that the Python mapping is an official CORBA
standard, it's pretty much set in stone. It can be extended or fixed
for bugs, but it will be very hard to have it changed.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --