[Guido]
uncertainty of the possibility to call close() from the destructor may have slowed that down.
[Phillip]
If you're talking about the bit about __del__ not working when hanging off a cycle, my apologies for creating that confusion, I misunderstood Tim's post.
No, I'm not talking about that.
If you're talking about the circular reference scenario involving exceptions, then I think I've already given a tentative explanation why such a cycle will not include the generator-iterator itself (only its frame) as long as the generator-iterator clears its frame's f_back when the frame is not in use. It would probably be a good idea to verify this, but I think the basic idea is sound.
Yes, the generator does clear its f_back when it's suspended.
The only scenario in which a generator-iterator would be uncollectable is if you took some action outside the iterator to pass it into itself, or if you stored the iterator in a global variable. However, even in the latter case, the phase of Python shutdown that clears module contents would break the cycle and cause the generator to finalize, albeit a bit late and perhaps in a broken way. Still, storage of generator-iterators in module globals is a very unlikely scenario, since it's more common to loop over such iterators than it is to store them in any kind of variable.
Sure. But I still have some reservations, since cycles can pop up in the strangest of places (especially when tracebacks are involved -- tracebacks have been causing problems due to cycles and keeping variables alive almost since Python's inception). I posted about this a while ago, but don't recall seeing a response that took my fear away. Unfortunately, discussing this is about 1000x easier when you have a shared drawing surface available -- I cannot even think about this myself without making drawings of object references... -- --Guido van Rossum (home page: http://www.python.org/~guido/)