Re: [Orbit-python-list] Uploaded patch

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

On Wednesday 16 August, Jason Tackaberry wrote:

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

Why are Python modules considered excess baggage when the IDL itself
isn't?  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?

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.

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

The mapping standard says that it must be possible to do just "import
CORBA", and get the default CORBA installation, so with compliant ORBs
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
do a bit of cunning module manipulation to support "import CORBA".

That aside, you don't need to modify import's behaviour at all. As
long as load_idl puts the modules in sys.modules, future imports for
those modules will use the ones which have already been loaded.


[...attributes...]
> > 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.

My argument is that "interface.attr = foo" is _less_ readable than
"interface._set_attr(foo)", since the former does not make it clear
that an operation invocation is being made.

Take the following piece of code:

  obj.foo = 1
  obj.foo = obj.foo + 2
  print obj.foo

What does it do?  At first glance, most people would assume that it
prints 3. But if obj is a CORBA object, there is no way of telling,
because the get and set operations underlying the attribute may not be
treating it like a genuine data member. Even if it is just a data
member, some other client might concurrently modify the attribute at
any stage between the four remote calls.

Of course, Python is flexible enough that all the same problems can
arise in a single non-CORBA program, if you design classes which are
sufficiently perverse and use threads. But people don't do that --
it's not the Python way. It just makes code hard to understand. Now
consider the following code:

  obj._set_foo(1)
  obj._set_foo(obj._get_foo() + 2)
  print obj._get_foo()

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.

Anyway, enough of my ranting.

Cheers,

Duncan.

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