[vtkusers] Status of VTK Python 3 wrapper support

[Berk Geveci]

Hi David,

Sounds great. I am glad that you are hooked on the wrappers :-) You have
done a lot of wonderful work on them and as a big Python fan I am very
grateful.

PS: Sorry for the late reply. I was on vacation.

Best,
-berk


On Fri, Aug 1, 2014 at 11:30 AM, David Gobbi <david.gobbi at gmail.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20140806/252b6ac2/attachment.html>