GitLab

This is no longer needed, and is needlessly restrictive.
It's best to have a header that can be used by multiple
versions of python.

When built with certain versions of Python, a VTK build with
VTK_WRAP_PYTHON enabled results in many build warnings. For example:

Python 2.7.10:

    c:\python27\include\pyconfig.h(444): warning C4005: 'HAVE_ROUND' : macro redefinition
              C:\dev\VTK\Utilities\Python\vtkPython.h(77) : see previous definition of 'HAVE_ROUND'

This warning occurs because both vtkPython.h and Python.h define the
HAVE_ROUND macro, but the definitions don't match. Python 2.7.9+ and
Python 3.4.2+ define HAVE_ROUND when compiling with Visual Studio 2013+
(see http://bugs.python.org/issue21958).

Python 3.4.1:

    c:\python34\include\pymath.h(22): warning C4273: 'round' : inconsistent dll linkage
              C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\math.h(516) : see previous definition of 'round'
    C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xtgmath.h(206): warning C4273: 'round' : inconsistent dll linkage
              C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\math.h(516) : see previous definition of 'round'

This warning occurs because neither Python.h nor vtkPython.h define HAVE_ROUND.

This commit removes the build warnings by:
- changing the HAVE_ROUND macro definition to match Python's definition
- removing the Python version check

PySys_GetObject/SetObject API continues to take char*  (instead of
const char*) till Python 3.4. Hence we need to use const_cast to avoid
warnings.

This module was missed in the first round of Python 3 compatibility
fixes.

In Python 3.5, they finally created a public function to convert
strings from local encoding to wchar_t unicode.  The old internal
function _Py_char2wchar() has been replaced by Py_DecodeLocale(),
which also handles UTF-16 surrogates for OS X.

Since Python 3.2, the python libraries and include directories can
have the suffixes m (pymalloc), u (wide unicode), and d (debug).
The first two (m and u) are now included in the default search path.
If someone wants the debug library on Linux/OS X, they must select
it explicitly.

Everything in this change came from the master branch of make.

VTK calls FindPythonInterp first, tries to find the python libraries that
match the version of the interpreter.  This wasn't working for the OS X
python 3.4 package from python.org, because the includes were stored in
the directory python3.2m instead of the directory python3.2.

The PyNumberMethods initializer has two more elements in Python 3.5,
for matrix multiplication.

The wxVTKRenderWindowInteractor seems to work fine, but the older
wxVTKRenderWindow is unable to bind the render window properly
because it hasn't been properly patched to keep it up-to-date with
the changes in VTK and/or wxWindows.

The tp_new slot was unconditionally checking the constructor args,
looking for a swig-style pointer.  This meant that if a vtk class
was subclassed in Python, the subclass constructor args were checked
in the same way regardless of whether it defined its own __init__
method.

If a wrapped C++ method returns std::string or "const char *", the
wrappers try to decode it as utf-8 in order to return a unicode str()
in Python 3.  Originally, this meant that any decoding error led to
a UnicodeDecodeError exception.  After this change, if decoding utf-8
fails, the C++ string is returned as a raw bytes() object.

For Python 2, this method operated like the cmp(a,b) method.  In
Python 3, there is no cmp(a,b) method, so instead this method now
returns (a < b) like the original C++ method.

Two major changes: 1) the vtkLoadPythonTkWidgets utility module is now
imported explicitly as a relative module, necessitating absolute_import.
The alternative is to import it as vtk.tk.vtkLoadPythonTkWidgets, which
makes the tk module less mobile, in case someone wanted to incorporate it
or the vtk module itself into a larger package (e.g. what paraview does).

2) I've explicitly added an "if" check for python3 before importing the
tkinter module.  This is done to ensure that an appropriate error is
reported if the module fails to load (i.e. so that it won't complain
about trying to import "tkinter" on Python 2, just because it had a
fallthrough on an attemp to import "Tkinter".

1) Change unicode string unicode string check in TestTemplates.py.
2) Eliminate some obsolete imports (like "exceptions").
3) Convert string to bytes in TestDataEncoder.py.

The python "buffer" and "memoryview" objects do not expose the pointer
to the underlying memory, they only expose the contents of the memory.
Likewise, if you check (buffer1 == buffer2) within python, then python
will iterate through both buffers to see if they have the same contents!
After all, for python, that's how equality is defined for sequence types.

This commit adds a method called buffer_shared(ob1, ob2) that checks to
see if two objects (e.g. arrays) expose the same block of memory via
their buffer interface.  It assumes that the "buf" pointer is the lowest
address of the buffer (i.e. the strides must be non-negative).

It also adds two changes to dataset_adapter.py:
1) The adapter now uses buffer_shared() instead of using "==" to compare
buffers, because as stated above "==" does the wrong thing.
2) It repairs an infinite recursion where __getattr__ called hasattr().
The infinite recursion was caught silently by hasattr() itself in python2,
but is exposed as a RuntimeError in python3.

A typo in vtkPythonArgs.cxx resulted in the use of a "char *" from a
deleted Python object.  I've fixed the typo and have completely
removed the code that can give rise to the invalid pointer.

This commit also changes a BuildBytes to actually build a Bytes object
on Python 3 (it was building a string).

Under Python 3.2, the default locale encoding will be used for 8-bit
strings rather than utf8 (similar to Python 2).  It wasn't until 3.3
that unicode objects kept a cached copy of the utf8 string.

Some quick py3k compatibility fixes caused these print statements
to generate much different output from before.  This fixes that.

This allows "make" to compile these files into pyc files, though
it does not provide full py3k compatibility.

This involved replacing map() with list comprehensions, changing the way
metaclasses are used, removing the __div__ method under python 3, and
using 'zip" instead of "izip" on python 3.

This change modifies the python code for the tests so that they are
cross-compatible between python 2 and python 3.  The new code will not
run on Python 2.5 or earlier, because only python 2.6 and 2.7 allow
py3k-friendly syntax.

The numpy_interface does not fully support python 3 yet, due to changes
in the way numeric operators work and the way type coercion is done.

This is a large change that adds conditional compilation to support
both python 2 and python 3.  The header vtkPythonCompatibility.h
does a lot of the necessary work:
1) PyInt is redefined to PyLong for py3k
2) PyString is redefied to PyUnicode for py3k
3) PyBytes is redefined to PyString for python 2

The get() method was incorrectly implemented and segfaulted.  Also,
with py3k, the keys() method returned a special object instead of
a plain list, and this caused the wrapping to fail.

Python 3 introduced a multi-dimensional buffer interface, which was
backported to Python 2.6 and Python 2.7.

This changes the return value of the "real_init" function from void
to PyObject *, in accordance with the new PyInit method.

Enum parameter types were missing from the python docstrings.  Also,
the PythonName utility function fits better in vtkWrapText.h.

The vtk_mangle member was exactly the same as the python name for
the class, so it can be retrieved from the PyTypeObject.  I also
renamed the vtk_cppname member to vtk_name and renamed its attrib
to __vtkname__.  This attrib is what the VTK GetClassName() method
returns.

This was the last generated type object that was exported.  Now that
it is static, the wrapper-specific import/export macros are no longer
needed.

The overloaded method resolution code in vtkPythonOverload.cxx used to
make assumptions about type based on the class name (e.g. vtk types start
with "vtk", python types start with "Py").  Now a distinct character code
is used for each type.