[Guido] > That same testcase prints the same output for me on Linux, with Python > 2.2, with a 2.3 from June 4th, and with 2.3 from current CVS: > > collected 3 > collected 51 > collected 9 > collected 0 > > and, at the end, collected 1 > > So there really are test cases that require more than one collection > to clean them up. Same here. I wish we understood why. Or that at least one of Neil and I understood why. > ... > But I can now reproduce on Linux what Neil did using the new -t option > that I just added to regrtest.py: > > ./python ../Lib/test/regrtest.py -t0 test_descr test_gc > > which tells me > > test test_gc failed -- test_list: actual 10, expected 1 > > When I put an extra gc.collect() call in test_gc.test_list(), the test > succeeds. > > Is this the right fix? No, but assuming there isn't a real bug here, repeating gc.collect() until it returns 0 would be -- as the self-contained program showed, we *may* need to call gc.collect() as many as 4 times before that happens. And if it's legit that it may need 4, I see no reason for believing there's any a priori upper bound on how many may be needed. And the test could have failed all along, even in 2.2; it apparently depends on how many times gc just happens to run before we get to test_gc. I'll check in a "drain it" fix to test_gc, but I'm still squirming. > I can't see anything particilarly wrong with subtype_clear() or the > slot-traversing subtype_traverse() in typeobject.c. I couldn't either, but in my case I had scant idea what it thought it was trying to do <0.9 wink>.
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