Re: [Orbit-python-list] Uploaded patch

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

> Why are Python modules considered excess baggage when the IDL itself
> isn't?  

Well, better worded as "seemingly unnecessary excess baggage."  I think
there might be a cleaner solution to the problem, that's all.  In case
there isn't, though, I'm willing to do whatever's necessary to adhere to
the mapping specification.  I do think it's important.

> As Martin von Loewis (the main author of the Python mapping)
> asks in comp.lang.python, how do you find the IDL file referenced by
> 
>   CORBA.load_idl("naming.idl")
> 
> Do you look on PYTHONPATH?  Some other IDL search path?  Just the
> current directory?  What about files #included in the file you load?

This is one of those unresolved issues that I decided to worry about
"later" while writing it.  I knew right away that load_idl() was a hack,
but it seemed the most obvious approach for dynamic IDL loading, and it's
also the way Owen Taylor's CORBA::ORBit (perl bindings) implemented it,
from which ORBit-Python was heavily based.

> I'm not saying that dynamic loading of IDL is always wrong (I've
> implemented it for omniORBpy after all), just that it isn't always
> ideal.

Well, ORBit-Python has no idl compiler, and I don't see that changing
soon (I've no motivation to write one), so I'll have to find some way to
massage this approach into complying with a specification that was written
with other intentions.

It does sound as though some magic is going to have to happen when importing
the CORBA module.  Suppose it fetches some sort of dictionary of IDL
modules that maps module and interface names to IDL files.  Then when
importing a module, it could first check this dictionary and call load_idl()
if such a mapping exists.  Of course there's lots of problems with this sort
of approach.  Either it means some sort of specific registry that users
will have to add IDL files to, or it means some overhead to scan through 
known IDL directories to generate this mapping at runtime.

> 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?  

> 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?

> Much more ugly, I agree. But how many people would assume that it
> prints 3?  It's much more obvious that something other than simple
> assignment is going on. I think that is a good thing, and worth the
> uglifying syntax.

Since ORBit-Python implements the accessor pairs now, users will have a
choice.  And your arguments are strong ones in favor of using that style,
but so long as both methods are available, I think everyone will be happy.
:)

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. :)

Jason.