tests failures against Pytest 8.2.0 about silx

[stanislavlevin]

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.

[vallsv]

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.

[t20100]

The SpecFile.__dealloc__ code is calling a method, so clearly out of the specification:

silx/src/silx/io/specfile.pyx

Lines 661 to 671 in 755fa6d

	def __dealloc__(self):
	"""Destructor: Calls SfClose(self.handle)"""
	self.close()
	def close(self):
	"""Close the file descriptor"""
	# handle is NULL if SfOpen failed
	if self.handle:
	if specfile_wrapper.SfClose(self.handle):
	_logger.warning("Error while closing SpecFile")
	self.handle = NULL

Calling close from __del__ instead of __dealloc__ should fix this.

https://cython.readthedocs.io/en/latest/src/userguide/special_methods.html#finalization-methods-dealloc-and-del

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.

[t20100]

Thanks for the bug report!

PR #4129 should fix it.