Python 3 support

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Python 3 support

Burnpanck
Hello everybody,

I have attempted to convert traits to python 3, the results of which you will find in my GitHub repository "burnpanck" in the "python3" branch. So far, it is tested to be compilable and importable under both python 2.7 and 3.2. In addition, it passes all unittests under 2.7 and almost all under 3.2. Feel free to check it out!

When converting the code, I tried to be backwards compatible with python 2.4, which is listed as the minimum requirement on http://code.enthought.com . I have not tested it though. Under python 2, I tried to keep the exact behaviour, but there are a few exceptions. For example, I do recall the following changes:
- TraitListObject now accepts "tlo[slice(a,b,c)] = value".
- Due to the string unification in python 3, if trait names are passes as unicode strings in python 2, there might be cases where traits will not behave exactly as before with respect to throwing exceptions.
- In traits/protocols/_speedups.pyx, there are references to a mysterious class named "ExtensionClass", which I assumed to a pre python 2 relict. I completely removed any references to ExtensionClass. Was this assessment correct?
- There might be a few very slight performance regressions, as to keep the code tidy, one or two "if" statements had to be added to ctraits.

Under python 3, there are a few changes in the behaviour with respect to python 2:
- int/long unification: Consistent with the Python C-API, I just removed any ctrait types of type int. On the python level, I did not deal with the "Int" trait in any special way, but apparently they still work. Either, by way of the communication between python- and c-traits, they actually get implemented using the long-ctrait, or, they automatically fall back to a python implementation, which of course is in fact a implementation of a long-trait as well. Since there is currently no c-implementation of a Range trait with long types, there is effectively no c-level Range trait at all any more in python 3.

Finally, I also ported pyface and traitsui, such that they build and import properly under python 3. However, since I was unable to build PySide for python 3, they are basically untested. I did not try any other GUI interface.

Cheers, burnpanck
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Python 3 support

Corran Webster
Very cool!  Thank you for working on this.

In terms of support of old Python versions, at this point I think that Enthought really only cares about support for 2.6 and 2.7 from the 2 series.  Supporting 2.5 might be nice, but at this point 2.4 is nearly a decade old and I wouldn't work too hard to keep backward compatibility.

Not sure if I have time to look over your code in the next few days, but I'll ping the team here and see if someone with the right skillset has some spare cycles.

-- Corran


On Wed, Apr 3, 2013 at 4:31 AM, Burnpanck <[hidden email]> wrote:
Hello everybody,

I have attempted to convert traits to python 3, the results of which you will find in my GitHub repository "burnpanck" in the "python3" branch. So far, it is tested to be compilable and importable under both python 2.7 and 3.2. In addition, it passes all unittests under 2.7 and almost all under 3.2. Feel free to check it out!

When converting the code, I tried to be backwards compatible with python 2.4, which is listed as the minimum requirement on http://code.enthought.com . I have not tested it though. Under python 2, I tried to keep the exact behaviour, but there are a few exceptions. For example, I do recall the following changes:
- TraitListObject now accepts "tlo[slice(a,b,c)] = value".
- Due to the string unification in python 3, if trait names are passes as unicode strings in python 2, there might be cases where traits will not behave exactly as before with respect to throwing exceptions.
- In traits/protocols/_speedups.pyx, there are references to a mysterious class named "ExtensionClass", which I assumed to a pre python 2 relict. I completely removed any references to ExtensionClass. Was this assessment correct?
- There might be a few very slight performance regressions, as to keep the code tidy, one or two "if" statements had to be added to ctraits.

Under python 3, there are a few changes in the behaviour with respect to python 2:
- int/long unification: Consistent with the Python C-API, I just removed any ctrait types of type int. On the python level, I did not deal with the "Int" trait in any special way, but apparently they still work. Either, by way of the communication between python- and c-traits, they actually get implemented using the long-ctrait, or, they automatically fall back to a python implementation, which of course is in fact a implementation of a long-trait as well. Since there is currently no c-implementation of a Range trait with long types, there is effectively no c-level Range trait at all any more in python 3.

Finally, I also ported pyface and traitsui, such that they build and import properly under python 3. However, since I was unable to build PySide for python 3, they are basically untested. I did not try any other GUI interface.

Cheers, burnpanck

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev



_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Python 3 support

Darren Dale
On Wed, Apr 3, 2013 at 11:14 AM, Corran Webster <[hidden email]> wrote:
> In terms of support of old Python versions, at this point I think that
> Enthought really only cares about support for 2.6 and 2.7 from the 2 series.
> Supporting 2.5 might be nice, but at this point 2.4 is nearly a decade old
> and I wouldn't work too hard to keep backward compatibility.

If I am not mistaken, traits currently requires python-2.5 or later,
due to the use of relative imports. (This change was made to allow
traits to be included as a subpackage in third-party libraries.)

Darren
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Python 3 support

Didrik Pinte-2
In reply to this post by Burnpanck
Hi Burnpanck.

This is great work. Your experience in the migration is really
valuable. One question: would you be able to update the Travis CI to
run the test suite (see
https://github.com/burnpanck/traits/blob/python3/.travis.yml).

They are a number of ongoing initiatives to get the C part of Traits
cleaned up (Traits4 repo, etc.) and updated to Cython. There is no
clear timeline around that but things get clearer.
I can see your experience being a real added value along those changes.

-- Didrik


On 3 April 2013 11:31, Burnpanck <[hidden email]> wrote:

> Hello everybody,
>
> I have attempted to convert traits to python 3, the results of which you
> will find in my GitHub repository "burnpanck" in the "python3" branch. So
> far, it is tested to be compilable and importable under both python 2.7 and
> 3.2. In addition, it passes all unittests under 2.7 and almost all under
> 3.2. Feel free to check it out!
>
> When converting the code, I tried to be backwards compatible with python
> 2.4, which is listed as the minimum requirement on http://code.enthought.com
> . I have not tested it though. Under python 2, I tried to keep the exact
> behaviour, but there are a few exceptions. For example, I do recall the
> following changes:
> - TraitListObject now accepts "tlo[slice(a,b,c)] = value".
> - Due to the string unification in python 3, if trait names are passes as
> unicode strings in python 2, there might be cases where traits will not
> behave exactly as before with respect to throwing exceptions.
> - In traits/protocols/_speedups.pyx, there are references to a mysterious
> class named "ExtensionClass", which I assumed to a pre python 2 relict. I
> completely removed any references to ExtensionClass. Was this assessment
> correct?
> - There might be a few very slight performance regressions, as to keep the
> code tidy, one or two "if" statements had to be added to ctraits.
>
> Under python 3, there are a few changes in the behaviour with respect to
> python 2:
> - int/long unification: Consistent with the Python C-API, I just removed any
> ctrait types of type int. On the python level, I did not deal with the "Int"
> trait in any special way, but apparently they still work. Either, by way of
> the communication between python- and c-traits, they actually get
> implemented using the long-ctrait, or, they automatically fall back to a
> python implementation, which of course is in fact a implementation of a
> long-trait as well. Since there is currently no c-implementation of a Range
> trait with long types, there is effectively no c-level Range trait at all
> any more in python 3.
>
> Finally, I also ported pyface and traitsui, such that they build and import
> properly under python 3. However, since I was unable to build PySide for
> python 3, they are basically untested. I did not try any other GUI
> interface.
>
> Cheers, burnpanck
>
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>



--
Didrik Pinte                               +32 475 665 668
                                                +44 1223 969515
Enthought Europe                      [hidden email]
Scientific Computing Solutions   http://www.enthought.com

The information contained in this message is Enthought confidential &
not to be dissiminated to outside parties without explicit prior
approval from sender.  This message is intended solely for the
addressee(s), If you are not the intended recipient, please contact
the sender by return e-mail and destroy all copies of the original
message.
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Python 3 support

Burnpanck
Hi Didrik

On 16.04.2013 15:11, Didrik Pinte wrote:
> This is great work. Your experience in the migration is really
> valuable. One question: would you be able to update the Travis CI to
> run the test suite (see
> https://github.com/burnpanck/traits/blob/python3/.travis.yml).
I have never worked with Travis CI before, but I definitely can put
"3.2" onto the list of python versions. I have no idea how Travis CI
works, but in principle the setup.py will automatically invoke 2to3 once
it is run using a python version 3 or higher. How will I see if it is
working? As far as I can tell, Travis CI does not run on my repo, will
filing a pull-request to enthought/traits change this?
> They are a number of ongoing initiatives to get the C part of Traits
> cleaned up (Traits4 repo, etc.) and updated to Cython. There is no
> clear timeline around that but things get clearer.
> I can see your experience being a real added value along those changes.
>
I definitely appreciate some clean up in the C part of traits, right now
some functionality is widely distributed in the source, making it
difficult to trace interactions. Ideally, I would like to see all
trait-type specific behaviour being defined on the particular trait,
hopefully simplifying cHasTraits. Since cTrait itself is quite complex
itself, I was wondering it one could not split the cTrait functionality
to a number of c-level cTrait-subtypes. Also, all traits should be a
subclass of a common super-type. Of course, this is fantasising, as such
changes would risk a lot of backwards incompatibilities. Maybe this
would be bearable when major python versions are switched at the same time?

Anyway, I'm looking forward to news on that front!

Yves
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev