This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients gregory.p.smith, loewis, pitrou, rhettinger, stutzbach
Date 2008-12-18.09:28:47
SpamBayes Score 1.4282276e-05
Marked as misclassified No
Message-id <1229592517.9355.7.camel@localhost>
In-reply-to <>
Le jeudi 18 décembre 2008 à 06:12 +0000, Martin v. Löwis a écrit :
> I think this approach is difficult to maintain, and also may miss some
> objects.

But what counts is where tuples can be created in massive numbers or
sizes: the eval loop, the tuple type's tp_new, and a couple of other
places. We don't need to optimize every single tuple created by the
interpreter or extension modules (and even the, one can simply call

> I'd rather see that integrated into collection: e.g. when iterating over
> survivors of a collection, check whether they can be untracked.

That's what I had tried at first, but it crashes. I haven't
investigated, but I suspect removing an object from the GC list while
that list is being walked isn't very well supported by the GC.

Also, this approach is more expensive since it involves checking tuples
again and again each time they are walked by the GC. The patch only does
it once, when the tuple is being built.
Date User Action Args
2008-12-18 09:28:49pitrousetrecipients: + pitrou, loewis, rhettinger, gregory.p.smith, stutzbach
2008-12-18 09:28:48pitroulinkissue4688 messages
2008-12-18 09:28:47pitroucreate