[vtk-developers] Patch to vtkWrapPython.c to make wrapped Python code GIL-friendly

[David Cole]

My point is simply this: if something is *probably* going to be 
incorrect, then force it to be incorrect early in the CMake 
configuration stage rather than wasting people's time with build 
settings that might not work. That's one of the beauties of CMake: you 
can detect problems early and inform the developers about ways to avoid 
them.

While it may not be practical for everybody to upgrade their Python 
installations, it is the safe thing to do if you need the threading 
support being discussed here in conjunction with VTK. The safe thing 
should be what happens by default. People who need older Pythons 
combined with current VTK can always force it to build on their own 
system from source code simply by removing the check from the CMakeLists 
file. Or they can stick with an older build of VTK until they can 
upgrade their Python...

I'm just suggesting detecting problems as early as possible and avoiding 
them by default. I don't mean to force any upgrades on anybody... ;-)


Cheers,
David


Sander Niemeijer wrote:

>
> On woensdag, jul 13, 2005, at 21:24 Europe/Amsterdam, Charl P. Botha 
> wrote:
>
>> On 7/13/05, David Cole <david.cole at kitware.com> wrote:
>>
>>> It's always best to prevent crashing in the first place... right? You
>>> could use a CMake construct like this:
>>>   GET_FILENAME_COMPONENT(LIBNAME ${PYTHON_LIBRARY} NAME_WE)
>>>   STRING(REGEX REPLACE "python" "" LIBVER "${LIBNAME}")
>>>   IF(LIBVER LESS 23)
>>>     MESSAGE(SEND_ERROR "VTK_WRAP_PYTHON requires a minimum of Python
>>> version 2.3.\nUpgrade python or set VTK_WRAP_PYTHON to OFF to avoid 
>>> this
>>> error.")
>>>   ENDIF(LIBVER LESS 23)
>>>
>>> ...if the following hold true:
>>> VTK_WRAP_PYTHON is ON
>>> PYTHON_LIBRARY is found/set
>>> python libs are always named pythonNN where NN can be legally compared
>>> to a value like 23... (Assuming future Python 3.0 will be named
>>> python30.lib/a/so/dll...)
>>
>>
>> This would force everybody to upgrade to python 2.3, which is not
>> always practical.
>
>
> I agree. It is still possible to use VTK with elder versions of Python 
> as long as threading is disabled.
>
>> Perhaps this check could be combined with threading
>> on/off, i.e. if someone has a python < 2.3 and wants python wrappings,
>> threading has to be deactivated.
>
>
> This can be tricky since threading needs to be turned off in both VTK 
> _and_ Python.
> If you want to add a check for threading then you should also check 
> whether Python was build without threading support otherwise things 
> may still break.
>
> Best regards,
> Sander
>
>