Why pdf.close must be called explicitly and not via a destructor ? about pypdfium2 HOT 5 CLOSED

I'm afraid we can't do this because the different close functions must be called in correct order, which can't be guaranteed with destructor methods. Using __del__() is discouraged in general.¹ Other libraries like pikepdf or pillow also provide close() instead.

There might be a weakref trick which Mike Kroutikov of pdfbrain is currently investigating, but I'm not convinced if this is a good idea for pypdfium2.

from pypdfium2.

See also innodatalabs/pdfbrain#4

__del__ object method is not guaranteed to be called in the refcount order when program exits. This caused random crashes at the exit of programms using pdfbrain.

from pypdfium2.

What @mkroutikov did with weakref doesn't work, I think (see innodatalabs/pdfbrain#6).

However, I believe this should be possible with __del__ anyway. We just need to keep references to parent objects (and their respective parents) and ensure none of them has been closed yet before closing the child object.

However, closing of child objects might then be skipped if parents and children are garbage collected in the same cycle.
I need to verify if closing the parent also frees the memory of the kids - if so, this is not a problem. Otherwise, we might be able to keep track of released child objects via a list of weak references and close them first, even if Python attempts to finalise parent before child...

from pypdfium2.

Actually, I had to revert this again because - despite the order checking - this does still trigger random segfaults on exit, see f59dc65

from pypdfium2.

I think I finally found a working way with weakref, see innodatalabs/pdfbrain#6 (comment).
I've started a branch: autoclose_via_weakref.

from pypdfium2.