[Python-Dev] Garbage collecting closures

Paul Prescod paul@prescod.net
Mon, 14 Apr 2003 14:45:19 -0700


Martin v. L=F6wis wrote:
> Paul Prescod <paul@prescod.net> writes:
>=20
>=20
>>I knew I'd hear that. ;) Overall, I agree. Anyhow, I'll give you some
>>background so you can understand my use case. Then you can decide for
>>yourself whether it is worth supporting.
>=20
>=20
> I think demonstrating use cases is futile, as people believe that what
> you want is unimplementable. Instead, if you would come forward with
> an implementation strategy, that would be more convincing.

I'm no going to advocate a particular strategy because I don't know=20
enough of the performance and implementation costs. But you asked for a=20
strategy so I'll at least suggest one. Python could run gc.collect()=20
after returning from functions containing nested recursive functions.=20
Perhaps an opcode flags these functions.

Arguably this happens rarely enough that predictability is more=20
important than performance in this case. (I admit again that it is=20
arguable!) Perhaps there would be some more precise way to tell=20
gc.collect to only inspect graphs containing the offending nested=20
function...or maybe you could be even more precise: if a function is=20
known to be a nested function and it has a single reference count then=20
could you say that the only reference is to itself recursively?

Of course if the function returned a closure and the closure depended on=20
a variable referencing an object then the object should live as long as=20
the closure. That's both expected and necessary.

  Paul Prescod