VTK/Python Wrapping FAQ

From KitwarePublic
Jump to navigationJump to search

VTK Python Wrapping System

Big Picture

All the automated wrapping code generation relies on the consistent coding style followed in the VTK header files and the use of the convenience macros. Specific markers (in comments) in the header mark parts that are not to be parsed (BTX/ETX). Basically, a target language specific parser parses the header file figures out suitable wrapper functions in the desired target language and spits out the wrapper code that is used to generate the wrappings.

Python Versions

Currently (Aug 2010), VTK is regularly tested with Python 2.5 and Python 2.6, and it should work with all Python 2.x versions. Python 1.x is no longer supported, the wrappers might compile but the examples will definitely not run under Python 1.x.

Python 3 support is planned, but there is no date set. This version of Python has introduced two very significant changes to the Python-C API that will require changes to the VTK wrapper code. Fortunately the Python 3 API is similar enough to the Python 2 API that it will be possible to support both at the same time (just as numpy does). The hardest part will be to make sure that all the tests and examples run under both Python 2 and Python 3, as the Python language itself has changed more significantly than its C API.

Erm bra, van wanner af SlickEdit jy? Wat het gorwed van super jed souped-up to hell and gone? *grin* yip, laat die mense in die kommersiele wereld maar die trends set


The VTK module for the vtk Python package is all in Wrapping/Python/vtk. There is a rambling README in Wrapping/Python that might be of some use. There is also a nice README_WRAP.txt in the same directory that is useful.

C++ that won't be wrapped

Note: this list refers to VTK releases 5.6 and earlier. For the development version of VTK, see the page on python wrapper enhancements.

  • Templates
  • Abstract classes - these are wrapped, and their static methods can be used, but they cannot be instantiated

Because they can't be directly instantiated. Abstract classes are identified as such by putting them in a named list in cmakelist.txt.

  • Anything marked as wrap exclude

This is also done via a named list in cmakelist.txt.

  • Anything put between //BTX and //ETX in the header file
  • Methods that take or return unbounded pointers

Methods like "GetTupleValue(int i, double *tuple)" aren't wrapped in python unless they have a signature like GetTupleValue(int i, double tuple[3]) so that the wrappers know how large the array is.

Likewise, methods like "double *GetTuple(int i)" aren't wrapped unless there is a hint so that the wrappers know how many values will be returned.

The wrappers don't do anything fancy like check how many components an array has in order to find out what size of tuple to use. The wrapping of a method is determined only by the method signature and the hints in VTK/Wrapping/hints.

CMake's role

Big Picture

I think all CMake does is to build the parser and organize the building of the generated code, link it correctly (which can be a bloody pain) etc. I don't think it directly does anything regarding the wrapper generation process. Any useful CMake macros are best gleaned by looking at CMake files (at least thats how I used to do it).

CMake Macros

1. VTK_WRAP_PYTHON3(${NAME}Python KitPython_SRCS "${WRAP_LIST}")

Will wrap the c++ files in WRAP_LIST into python, outputting a list of transformed files into KitPython_SRCS.


Will take those outputs, and some optional additional ones, and create a library.

3. PYTHON_ADD_MODULE(${NAME}Python ${NAME}PythonInit.cxx)

Will produce a python module that links in the library so that the wrapped code is more easily callable via python.

That is what ParaView's WRAP_PLUGIN_FOR_PYTHON macro does anyway.

Excluding files from being wrapped

You can tell the wrapper to ignore certain files by using this in your CMakeLists.txt:


Other Topics

Using VTK objects in code wrapped with Boost.Python

Example from and to python converters