[omniORB] omniORBpy and Python 3.0

[Viktor Kerkez]

Is there any plans for porting omniORBpy to Python 3.0 when it comes out?

Cheers,

Viktor.

[Thorsten Glaser]

Post by Viktor Kerkez
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 ?

//Thorsten

[Andrew Edem]

On Sep 23, 2008, at 11:44 AM, Thorsten Glaser wrot

Post by Thorsten Glaser

Post by Viktor Kerkez
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.

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.

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

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.

A very interesting question indeed :)

-Andrew

[Duncan Grisby]

Post by Andrew Edem
On Sep 23, 2008, at 11:44 AM, Thorsten Glaser wrot

Post by Thorsten Glaser

Post by Viktor Kerkez
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.

Post by Andrew Edem
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.

Post by Andrew Edem
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.

Post by Andrew Edem
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.