[Python-Dev] Garbage collecting closures (original) (raw)
Paul Prescod paul@prescod.net
Mon, 14 Apr 2003 14:45:19 -0700
- Previous message: [Python-Dev] Garbage collecting closures
- Next message: [Python-Dev] Garbage collecting closures
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] Garbage collecting closures
- Next message: [Python-Dev] Garbage collecting closures
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]