[Orbit-python-list] Re: [DO-SIG] Implementing proprietary extensions

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

On Wednesday 11 April, Jason Tackaberry wrote:

> Right now ORBit-Python implements a few extensions, such as transparent
> accessors (through __setattr__ and __getattr__).  These extensions don't
> really break the spec since they needn't be used at all.  However
> recently I've had a number of requests to implement coercion between
> CORBA.Any and Python objects.   This will obviously break the spec in
> the case of CORBA.Any return values.

Interesting. I can see how it's easy to return Python objects when
unmarshalling an Any, but how would you do the marshalling side?  How
can you tell if something like "hello" is meant to be a string or a
sequence<octet>, or a sequence<char>, or a 5 element array of octet or
char?

> So I was wondering what the best approach would be to enable such
> proprietary enhancements in ORBit-Python.  I see 3 different "modes"
> that would change the way the module behaves:

The modes seem sensible to me.

[...]
>     from ORBit import enhanced
> or
>     from ORBit import strict
> 
> Any comments or thoughts on this approach?

Personally, I don't think that's very nice at all. I don't like the
__future__ thing either. I think it's confusing to re-use the import
mechanism to do something altogether different.  I'd be inclined to go
for something like

  import ORBit
  ORBit.mapping_mode(ORBit.ENHANCED)

or perhaps

  ORBit.mapping_mode("enhanced")


Cheers,

Duncan.

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