[vtkusers] Status of VTK Python 3 wrapper support

[David Gobbi]

Hi Berk,

Thanks for the insight into how this will impact your customers.  I wasn't
suggesting the the conversion of the tests be done now, or even before
the core.  And, yes, you're probably right that 2-to-3 is the way to go until
the major sites are ready to switch to python3.

For myself, there are two major wrapper-related tasks that have far higher
priority than py3k:

1) wrap enum types (so that enum types can be used as method args),
and also wrap namespaces, since these are blockers for some code that
I want to wrap.

2) eliminate the "PyVTKClass" type, which relies on an obsolete metaclass
mechanism (search for "Don Beaudry hack" if you're curious) and instead
use python's unified type/class extension system.

For #2, I'll see if I can put up a wiki page with more detail.  But I don't have
time to move forward on either 1 or 2 until the fall.  And you aren't going
to see me pushing for py3k, because I still have no need for it myself.  I
just want to be involved when the conversion occurs, because wrapper
stuff is fun.

 - David


On Fri, Aug 1, 2014 at 8:11 AM, Berk Geveci <berk.geveci at kitware.com> wrote:
> Hi David and others,
>
> I don't think that this workflow would work for us. Most of our
> collaborators, specially in the supercomputing community, are going to take
> a while longer to move to Python 3. So as a team, we need to continue to do
> our day-to-day work using Python 2. So having to go through a 3-to-2
> conversion mechanism would be very cumbersome. We would have to regularly
> maintain 2 builds, do the development in 3 then move to the 2 build, test
> etc.
>
> I suggest taking smaller steps. Starting with porting of the core modules
> (not the tests) and seeing what will be involved in maintaining both 2 and 3
> versions (or a 2-to-3 conversion on the fly) would be my suggestion. Once we
> can demonstrate the maintainability of this, I suspect that doing a 2-to-3
> conversion on the fly for the tests would be pretty easy.
>
> Best,
> -berk
>
>
> On Thu, Jul 31, 2014 at 4:15 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>
>> On Thu, Jul 31, 2014 at 6:44 AM, diego0020 <da.angulo39 at uniandes.edu.co>
>> wrote:
>> >
>> > But I am also looking forward to this. Is there anything we could do to
>> > push
>> > support for python 3 forward?
>>
>> There has been some discussion about converting all of the python
>> tests and examples, which is a part of the process where extra
>> manpower would be a big asset.  I imagine that the conversion will
>> go something like this:
>>
>> 1) Someone will run 2to3 on all the python code, and then make
>> sure that it can be byte-compiled with python3 (it will be too early
>> at this stage to actually run the code, but making sure that it
>> byte-compiles will be a good first step).
>>
>> 2) Lots of people will then pick through the code to fix conversion
>> errors and to make sure that the code actually looks like good
>> python3 code.
>>
>> 3) Finally, someone will add some CMake magic to VTK so that if VTK
>> is built against python2, cmake will run 3to2 on all of these new python3
>> files and put the equivalent python2 code into the VTK build
>> directory.  This is the magic that is needed to make sure that VTK
>> will be able to support both python2 and python3.
>>
>> So any assistance with the above process would be a big help.  In
>> particular, it would be very useful if someone could verify that item
>> (3) is even feasible: in the end it might be necessary to have hand-
>> written python2 and python3 exist side-by-side instead of using
>> automatic conversion.  It _should_ be feasible, since the VTK
>> tests used automated tcl-to-python conversion for many years,
>> and python3 to python2 should be much easier than tcl to python.
>>
>>  - David