If by "hissy fit" you mean "gcmodule properly moves generators to the
list of objects with finalizers, thereby preventing catastrophes",
right, that's an intended hissy fit ;-)
Well, I meant 'the durned thing refuses to do what I want it to do', which is clear cycles. I guess the hissy fit was mine ;)
Did the best I could above, short of explaining exactly how failing to
identify an object with a finalizer can lead to disaster.
Short course: gc obviously needs to know which objects are and are not
trash. If a finalizer is associated with an object in cyclic trash,
then trash objects are potentially visible _from_ the finalizer, and
therefore can be resurrected by running the finalizer. gc must
therefore identify all trash objects reachable from trash objects with
finalizers, because running finalizers _may_ make all such objects
"not trash" again. Getting any part of that wrong can lead to calling
tp_clear on an object that a finalizer actually resurrects, leading to
symptoms from "hey, all the attributes on my object suddenly vanished
by magic, for no reason at all" to segfaults.
So does that make all cycles involving only objects with finalizers impervious to cycle-gc? I guess it'd have to be that way. That also means I can stop searching for leaks in the C code, as we'll never be able to fix them all, anyway (although 'good code' could manually break many of the cycles.) At least not while keeping the tp_del of generator objects, not to mention avoiding finalizers on other builtin objects. (None seem to have them at the moment, they all do their stuff in tp_dealloc, which I guess doesn't allow objects to reincarnate themselves.)
I'll see about fixing the Python code to avoid or explicitly break the cycles. Maybe we can patch regrtest.py to take into account uncollectable cycles, so that it could report them separately from refleaks. I'm going to think about all this first, though.
Hrrm-
hrrm'ly y'rs,