[omniORB] omniORBpy and Python 3.0

[Duncan Grisby]

On Tuesday 23 September, Andrew Edem wrote:

> On Sep 23, 2008, at 11:44 AM, Thorsten Glaser wrot
> > Viktor Kerkez dixit:
> >
> >> Is there any plans for porting omniORBpy to Python 3.0 when it
> >> comes out?
> >
> > As far as I was taught, the Python CORBA language mapping mandates
> > using old-style classes, which are (AFAIHH) to die with Python 2.6
> > already. So this would be pretty much impossible, unless a
> > nōn-standard way were to be chosen. Interesting question ☺
> 
> Are you sure that old style classes are to be removed from 2.6? I
> can't find any reference to that in the release notes.

Nothing that affects omniORBpy has changed in 2.6. omniORBpy worked fine
with 2.6 rc 1 when I tried it.

> Regardless, though, they are definitely gone in 3.0. However, I can't
> find any reference to either new or old-style classes in version 1.2
> of the language binding, anyway.

There's nothing in the language mapping that mentions new or old-style
classes, so there's no issue there.

> But, even so, it brings me to wonder why that would make a difference,
> aside from changing all classes to inherit from object.

With Python 3.0, you don't need to inherit from object to get a
new-style class. All classes are new-style.

> I think that the biggest problem would be the syntax changes that
> would require a fork of all the python code in omniORB, and that could
> get difficult to maintain.

There are several issues.

First of all, the language mapping has to be updated. The current
mapping predates Unicode and bool support in Python, so it's already out
of date for current 2.x Python, but generally it's possible to follow
the intent of the mapping. With Python 3.0, things are more
fundamentally changed. In particular, it is no longer appropriate to map
sequence<octet> to Python string -- it should instead map to the new
bytes type.

Then, as you say, the code base will have to be changed to cope with the
language changes. A lot of omniORBpy is actually implemented in C++,
using the Python C API, so I expect it is going to be somewhat painful
and disruptive to port it. I suspect it won't be sensible to try to
support both Python 2.x and 3.x in one code base.

I've been intending to look into Python 3 support, but I haven't had a
chance to look yet. If anyone wants to bite the bullet and give it a go,
let me know and we can coordinate.

Cheers,

Duncan.

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