FYI, and without taking time for non-trivial analysis. I ran the non-ZEO
Zope3 tests with a Python patched to treat weakrefs with callbacks as
reachable (this was patch-finalizer.txt, attached to a msg I sent to
python-dev last night).
The first test to leave stuff in gc.garbage then:
The following test left garbage:
test_created (bugtracker.browser.tests.test_bug.BugBaseViewTest)
65
where 65 is len(gc.garbage) after the test finished. From there it climbed
steadily. By the time the functional tests ended, the Python process was
about 575MB, and gc.garbage contained 324,056 weakrefs.
I haven't investigated why it happens, but that it *does* happen in an app
that believes it's well-behaved suggests that "practicality beats purity"
would win in the end (i.e., no matter how elegant the approach, if it's too
hard to live with, it won't fly).
Of course nothing is left in gc.garbage here under 2.3.4 or 2.4b2, or under
2.4b2 + patch-callback. Under the latter, the Python process tops out at
about 150MB.
These were all with debug builds of Python, so process sizes are
substantially larger than with release builds (the object header is 2
pointers bigger in a debug build, and every object gotten via pymalloc grows
16 debug pad bytes, and everything gotten via PyMem_XYZ() gets pymalloc
debug padding too).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4