[vtkusers] When must I be weary of Python garbage collection?

[Elvis Stansvik]

2016-02-24 14:38 GMT+01:00 David Gobbi <david.gobbi at gmail.com>:

> On Wed, Feb 24, 2016 at 2:46 AM, Elvis Stansvik <
> elvis.stansvik at orexplore.com> wrote:
>>
>>
>> So my question is, can I always rely on this behavior when working with
>> pipelines through the Python wrappers? Or are there cases where VTK will do
>> things in C++ "behind the back" of the Python garbage collector?
>>
>
> Yes, you can rely on this behavior.  As expected, the vtkRenderWindow C++
> object holds a reference to the renderer, which holds references, to the
> actors, etc.
>
> The Python wrappers provide a python "wrapper" object for each C++ object
> that is exposed to python.  At the end of the scope, the reference count of
> the python object is decref'd.  If this causes the python object to
> destruct, then the reference count of the underlying C++ object is
> decref'd.  The underlying C++ object destructs if its reference count
> reaches zero.
>
>
>
>> And in fact, most of the time you probably want to keep references to a
>> lot of things, to be able to reconfigure the pipeline. I'm just wondering
>> if there are any gotchas to watch out for wrt to garbage collection when
>> not keeping references. If there are any "best practices" so to speak.
>>
>
> There are no best practices, because garbage collection is something that
> most users are not supposed to worry about.
>

Thanks a lot for the clarifications. The reason I was asking was because I
was working with some VTK Python code that looked like it was being very
careful to keep a reference to certain objects. But I realize now that this
was probably mostly an artifact of how the code was structured.


> Because garbage collection is done via reference counting, sometimes gc is
> delayed due to reference cycles.  But both VTK and Python have cycle
> detection in their garbage collectors.
>

Ah yes, I remember reading that observers can give rise to reference cycles.

Elvis


>  - David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160224/991c50ee/attachment.html>