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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4