[vtkusers] VTK Python3 support

[Arnd Baecker]

On Thu, 5 Mar 2015, David Gobbi wrote:

> As far as I'm aware, python 3 support hasn't moved forward since the last time it came up on the list.  I think
> that, for too many of us, python is python and python2 is available on every machine we use.
> Issues:
> 1) VTK wrapping still uses old-style classes.  I've been meaning to fix this.
> 2) Basic compile issues and cross-compatibility for py3 and py2 - we received a patch that fixes some of these
> issues.
> 3) Conversion of examples and tests to py3... this is a biggie!  Lots of community help required.
> 
> Overall, I've just been waiting for py3k to become dominant... but python2 is still the default python on OS X
> and on most of the linux systems that I use.  My guess is that Kitware is in the same position.  The demand for
> py3k support just doesn't seem to be there yet, even after all these years.
> 
> So of course, if anyone out there has a need for py3k, please let us know!  Compatibility with Blender has come
> up before.

Well, for our code basis we would like to move forward
to python 3 and the pressure is getting stronger now because for some 
packages we are using the development only continues for python 3.
On the other hand VTK (via tvtk and Mayavi) is an important element for 
several of our applications.
For Mayavi the situation is discussed for example here:
   https://github.com/enthought/mayavi/issues/84

There are projects considering to move away from VTK (and/or Mayavi)
because of its lack of python 3 support, see e.g.:
   https://github.com/menpo/menpo/issues/419

I would also suspect that sometimes VTK is not considered for new projects 
because the transition to python 3 is not happening/foreseeable.

Another aspect: I have been using python for teaching computational
physics for about 12 years now. I really would like to use python 3 from 
now on (so that the students don't consider me old-fashioned ... ;-)
However, that would also mean that I could not introduce them to cool 
stuff which can be done using VTK ...

Hope that gives some (convincing?) arguments in favor of Python 3 support.

Now, some thoughts on the conversion:
Maybe there is a bit of a hen-and-egg problem: as long
as the conversion of the wrapper has not been done,
the conversion of the examples and tests might seem not meaningful.

But maybe the examples and tests could be converted already now
so that they would run both under python 2 and
(in principle also) python 3.
For our small projects I have made good experiences with such an approach
by manually converting "problematic" statements.
(E.g. including some
from __future import division, print_function, absolute_import
and doing the necessary changes to the usage of divisions and print
a lot of code already runs fine on both python 2 and python 3.
A tool which could also help might be pylint:
In a recent version it recieved the option --py3k  so that
    pylint --py3k  algorithms.py
lists all problematic lines.
So with this one could go over all .py files and convert them
such that they should still work on python 2 (which can be tested)
and also python 3 (which can only be tested once the wrapper
has been converted).

To me it seems that 1) and 2) require in-depth technical skills
while 3) would be mainly man-power (working through the .py files
according to some to-be-discussed rules).

David, Is it necessary that 1) and 2) are tackled by you,
or do you think that this would be feasable as a GSoC project?
Concerning 3): I would be willing to spend some
time to help in the conversion - maybe I can also get some
money for a student to help.

So as you can see, I am very much in favour of seeing
a python 3 capable VTK as soon as possible ... ;-)

Best, Arnd


> On Thu, Mar 5, 2015 at 9:34 AM, Tarcísio Fischer <tarcisio.fischer.cco at gmail.com> wrote:
>       I saw that we now have vtk6.2.0, I was just wondering... How is python3 support going? How far are we
>       from full python3 support?
> 
> Thanks.
> 
> 
> 
>