We've got a library that supports py 3.8 .. 3.12 I though I'd give it a go with newest pypy release, and a couple of unit tests fail. I've traced it down to the expectation that objects will disappear from weakref.WeakKeyDictionary. In some cases, this is a user-facing thing, we issue a warning for "unused" resources, by virtue of them missing from the weak container when we expect the user code to keep the reference around. Is there a good idiom or some way to support this behaviour with pypy? Thanks, Dima Tisnek
This is just my 2 cents as a PyPy user. CPython eagerly destroys unreferenced objects while PyPy will destroy them eventually. I ran into a problem with the requests library where it would create connection pool object every request, and the unreferenced pool would not be cleaned up immediately which caused the maximum number of open file descriptors to be reached (if I recall correctly). The solution to my case was calling `gc.collect_step()` (a PyPy-only function) after each request. You can also try the standard `gc.collect()` function which may be more reliable for a unit test to ensure any unreferenced objects are garbage collected. This may not help with the general use of your library though.
On 02.09.24 18:02, cpburnz@gmail.com wrote:
This is just my 2 cents as a PyPy user. CPython eagerly destroys unreferenced objects while PyPy will destroy them eventually. I ran into a problem with the requests library where it would create connection pool object every request, and the unreferenced pool would not be cleaned up immediately which caused the maximum number of open file descriptors to be reached (if I recall correctly). The solution to my case was calling `gc.collect_step()` (a PyPy-only function) after each request. You can also try the standard `gc.collect()` function which may be more reliable for a unit test to ensure any unreferenced objects are garbage collected. This may not help with the general use of your library though.
We have similar issues with garbage collection in PySide on PyPy. To reliably get rid of objects, we are calling gc.collect() twice. ciao -- Chris -- Christian Tismer-Sperling :^) tismer@stackless.com Software Consulting : http://www.stackless.com/ Strandstr. 37 : https://www.qt.io/qt-for-python 24217 Schönberg : GPG key -> 0xE7301150FB7BEE0E phone +49 176 624 88888
This is just my 2 cents as a PyPy user. CPython eagerly destroys unreferenced objects while PyPy will destroy them eventually. I ran into a problem with the requests library where it would create connection pool object every request, and the unreferenced pool would not be cleaned up immediately which caused the maximum number of open file descriptors to be reached (if I recall correctly). The solution to my case was calling `gc.collect_step()` (a PyPy-only function) after each request. You can also try the standard `gc.collect()` function which may be more reliable for a unit test to ensure any unreferenced objects are garbage collected. This may not help with the general use of your library though.
On 02.09.24 18:02, cpburnz@gmail.com wrote:
This is just my 2 cents as a PyPy user. CPython eagerly destroys unreferenced objects while PyPy will destroy them eventually. I ran into a problem with the requests library where it would create connection pool object every request, and the unreferenced pool would not be cleaned up immediately which caused the maximum number of open file descriptors to be reached (if I recall correctly). The solution to my case was calling `gc.collect_step()` (a PyPy-only function) after each request. You can also try the standard `gc.collect()` function which may be more reliable for a unit test to ensure any unreferenced objects are garbage collected. This may not help with the general use of your library though.
We have similar issues with garbage collection in PySide on PyPy. To reliably get rid of objects, we are calling gc.collect() twice. ciao -- Chris -- Christian Tismer-Sperling :^) tismer@stackless.com Software Consulting : http://www.stackless.com/ Strandstr. 37 : https://www.qt.io/qt-for-python 24217 Schönberg : GPG key -> 0xE7301150FB7BEE0E phone +49 176 624 88888
participants (3)
-
Christian Tismer-Sperling -
cpburnz＠gmail.com -
Dima Tisnek