[vtkusers] Status of VTK Python 3 wrapper support

[Matthew Brett]

Hi,

On Wed, Aug 6, 2014 at 4:25 AM, Berk Geveci <berk.geveci at kitware.com> wrote:
> 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.

Just for reference, nearly all of the big scientific python projects
(numpy, scipy, matplotlib, ipython, sympy) have switched to using a
common code-base for Python 2 / Python 3.  [1, 2].  This now seems to
be the standard Python advice if you want to keep Python 2
compatibility [3] (in days gone past, the standard advice was to use
2to3).  The numerical Python community is likely to start switching
over to standardizing on Python 3 fairly soon (over the next couple of
years), and all standard numerical packages now have Python 3 support.
In general our experience has been that when we used a compatibility
file such as that provided by the 'six' [6] project, and with good
tests, porting to a Python 2 / 3 compatible code base was a lot easier
than we had feared.

Cheers,

Matthew

[1] http://ondrejcertik.blogspot.com/2013/08/how-to-support-both-python-2-and-3.html
[2] http://asmeurersympy.wordpress.com/2013/08/22/python-3-single-codebase-vs-2to3
[3] https://docs.python.org/3/howto/pyporting.html
[6] https://pypi.python.org/pypi/six