Re: [Orbit-python-list] Uploaded patch

[Jason T. <ta...@li...>]

> severely weakened by the fact that none of the other Python ORBs
> support it. I believe that this disagreement between ORBs will put
> people off from using Python with CORBA.

I'm all for working to reach standards compliance.  I definitely see the
advantage being able to run python code across different ORBs with few
changes.  Unfortunately I fear this is going to require some pretty
horribly ugly hacks.

> with "import M". One way around this is to write small modules which
> do nothing but call CORBA.load_idl(). A simple IDL compiler fragment
> which just wrote such modules would comply with the mapping
> requirement, while keeping the general dynamic IDL approach.

But it also means you have to carry around excess baggage, which is one of
the nicely avoided by dynamic IDL.  While I'll concede this is going to
require some hack, I'd prefer whatever hack we choose to be simple and
minimally intrusive.

A small degree of source editing is required to use a different ORB
anyway (for example by changing the 'from ORB import CORBA' line), so I
could require that CORBA.load_idl be invoked immediately after importing
the CORBA module, and then override import (using __import__) to ignore
modules that exist from the IDLs.  So, something like:

from ORBit import CORBA                      # ORB specific
CORBA.load_idls('M.idl', 'foo.idl')          # ORB specific
import M                                     # ignored by __import__
import foo                                   # ignored by __import__

Thus, someone who switches from ORBit-Python to omniORBpy, say, can just
change the first line, and delete the second.

> involves a remote call, and can raise any of the CORBA system
> exceptions. I think it's far better to make it look like what it is: a
> method invocation.

Well I'd considered this, but I think the elegance, simplicity, and
readability of the 'interface.attr = foo' approach are good arguments as
well, and I would favor this when using ORBit-Python for situations where
using ORBit makes sense (in a Gnome application, say).  All the arguments
are perfectly legit, and I admit I'm a little torn about the issue.

Although, thanks to Roland Mas' efforts, ORBit-Python supports the accessor
pairs now.  

Regards,
Jason.