[vtkusers] Status of VTK Python 3 wrapper support
matthew.brett at gmail.com
Wed Aug 6 13:33:07 EDT 2014
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
> PS: Sorry for the late reply. I was on vacation.
> 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
>> 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
>> 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  (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'  project, and with good
tests, porting to a Python 2 / 3 compatible code base was a lot easier
than we had feared.
More information about the vtkusers