Author Anssi.Kääriäinen
Recipients Anssi.Kääriäinen, amaury.forgeotdarc
Date 2013-03-19.20:28:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1363724898.27.0.698762091821.issue17468@psf.upfronthosting.co.za>
In-reply-to
Content
I am trying to read the code, and it seems objects of type generator are uncollectable if the code of the generator has a block of other type than SETUP_LOOP. I can see how try-finally for example in the generator would cause problems - the finally might reference objects which are already collected. But plain try-except? What is the problem with that? (Not saying there isn't one, I am new to the code...).

I tried to change the code to also allow collecting generators with plain try-except (add in a check for SETUP_EXCEPTION in addition to SETUP_LOOP in PyGen_NeedsFinalizing()). This resolves the leak, and all tests pass. I can't tell if it is actually safe to return 0 in SETUP_EXCEPTION case.

After the change try-finally will still leak but that seems correct.

Maybe this limitation should be documented? I think I understand now why finally or with statement inside a cyclic referenced generator will end up in gc.garbage. However the docs tell that only objects with __del__ defined will leak. From user perspective generator doesn't have __del__, at least it is not to be found with pdb. Generators have potentially unsafe finalizer code but that isn't technically equivalent to having __del__ method defined as far as I can tell.
History
Date User Action Args
2013-03-19 20:28:18Anssi.Kääriäinensetrecipients: + Anssi.Kääriäinen, amaury.forgeotdarc
2013-03-19 20:28:18Anssi.Kääriäinensetmessageid: <1363724898.27.0.698762091821.issue17468@psf.upfronthosting.co.za>
2013-03-19 20:28:18Anssi.Kääriäinenlinkissue17468 messages
2013-03-19 20:28:17Anssi.Kääriäinencreate