[omniORB] IDL to Python language mapping update?

[Duncan Grisby]

On Wed, 2011-03-16 at 18:51 -0500, Brian Neal wrote:

> I have a short list of things off the top of my head:

Sorry for taking ages to reply to this. A lot of these things are
actually already done, or under way.

> * clarify use of unicode and bytes as the existing spec was written
> before Python had unicode

Unicode is already used for wstring and whcar, of course. A Python 3
version should use unicode for string and char too. bytes should be used
for sequence<octet>. I think that will be the biggest change for Python
3 support.

> * use Python bool

omniORBpy already does. It still accepts int and long when bool is
expected, but it always uses bool itself.

On a related note, another Python 3 change is the removal of the int
type, but that's relatively minor since omniORBpy accepts long
everywhere int is expected already.

> * I had not thought of decimal; you have a good idea there.

IDL fixed should indeed map to decimal.Decimal. Although does anyone
actually use IDL fixed?  I wouldn't be sure it's worth the effort.

> * Along those lines, perhaps use named tuples for IDL structs?

I don't think that would be good -- structs should be mutable.

> * Use of Python property attributes to map IDL properties to

omniORBpy on trunk in svn does that, in a way that's backwards
compatible with the standard _get_attr / _set_attr naming. Clients can
use property syntax; servers can either implement the attributes with
the standard names or with properties.


I think the biggest challenge with Python 3 support is how to structure
the source. The changes will be sufficiently pervasive that I don't
think it will be sensible to have a single source for both Python 2 and
Python 3 support, which will lead to the risk of divergence between the
implementations. I'm open to suggestions if anyone's looked into it.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --