[James Y Knigh] > But you're missing the point -- there's a *reason* that __del__ > interferes with cyclic GC. It doesn't just do it for the heck of it! > You can't simply have the C delete call into python code...the > objects the generator has references to may be invalid objects > already because they've been cleared to break a cycle. If you want to > execute python code on collection of a generator, it must be done via > __del__, or else it'll be horribly, horribly broken.
Thank you for reminding me -- that's indeed the reason, and it applies here. I think in the past I've unsuccessfully tried to argue that if a cycle contains exactly one object with a Python-invoking finalizer, that finalizer could be invoked before breaking the cycle. I still think that's a sensible proposal, and generators may be the use case to finally implement it. All this suggests that generators should indeed have a __del__() method which is synonymous with close() (I want close() to be the user-facing API). BTW I think that close() and __del__() should raise an exception when the throw(GeneratorExit) call doesn't end up either re-raising GeneratorExit or raising StopIteration. The framework for calling __del__() takes care of handling this exception (by printing and then ignoring it). Raymond take notice if you're still working on the PEP. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
