Closed stanislavlevin closed 3 weeks ago
Sounds like it's a call during the termination phase of python.
At this stage, access to object/module/package attributes are unpredictable. Because this objects was potentiall already released. That's a problem on it's own with the Specfile object. I mean __dealloc__
should maybe be protected against that.
But it also means this tests from test_specfilewrapper
also do not clean up properly the resources. The resources should not be alive after the tests.
This is what docs say about __dealloc__
:
https://cython.readthedocs.io/en/latest/src/userguide/special_methods.html#finalization-methods-dealloc-and-del
You need to be careful what you do in a dealloc() method. By the time your dealloc() method is called, the object may already have been partially destroyed and may not be in a valid state as far as Python is concerned, so you should avoid invoking any Python operations which might touch the object. In particular, don’t call any other methods of the object or do anything which might cause the object to be resurrected. It’s best if you stick to just deallocating C data.
The SpecFile.__dealloc__
code is calling a method, so clearly out of the specification:
Calling close
from __del__
instead of __dealloc__
should fix this.
Python 3.4 made it possible for extension types to safely define finalizers for objects. When running a Cython module on Python 3.4 and higher you can add a
__del__()
method to extension types in order to perform Python cleanup operations. When the__del__()
is called the object is still in a valid state (unlike in the case of__dealloc__()
), permitting the use of Python operations on its class members. On Python <3.4__del__()
will not be called.
Thanks for the bug report!
PR #4129 should fix it.
As of Pytest 8.2.0 (bisected to https://github.com/pytest-dev/pytest/pull/12096)
silx
' tests suite fails, for example:Not sure if this is
silx
issue and anything can be done on its side.