[Python-Dev] gcmodule issue w/adding __del__ to generator objects

[Phillip J. Eby]

Argh!  My email client's shortcut for Send is Ctrl-E, which is the same as 
end-of-line in the editor I've been using all day.  Anyway, the problem is 
that it seems to me as though actually checking for tp_del is too 
aggressive (conservative?) for generators, because sometimes a generator 
object is finished or un-started, and therefore can't resurrect objects 
during close().  However, I don't really know how to implement another 
strategy; gcmodule isn't exactly my forte.  :)  Any input from the GC gurus 
would be appreciated.  Thanks!

At 05:56 PM 6/18/2005 -0400, Phillip J. Eby wrote:
>At 05:50 PM 6/18/2005 -0400, Phillip J. Eby wrote:
> >Working on the PEP 342/343 generator enhancements, I've got working
> >send/throw/close() methods, but am not sure how to deal with getting
> >__del__ to invoke close().  Naturally, I can add a "__del__" entry to its
> >methods list easily enough, but the 'has_finalizer()' function in
> >gcmodule.c only checks for a __del__ attribute on instance objects, and for
> >tp_del on heap types.
> >
> >It looks to me like the correct fix would be to check for tp_del always,
> >not just on heap types.  However, when I tried this, I started getting
> >warnings from the tests, saying that 22 uncollectable objects were being
> >created (all generators, in test_generators).
> >
> >It seems that the tests create cycles via globals(), since they define a
> >bunch of generator functions and then call them, saving the generator
> >iterators (or objects that reference them) in global variables
> >
> >after investigating this a bit, it seems to me that either has_finalizer()
> >needs to
>
>Whoops.  I hit send by accident.  Anyway, the issue seems to mostly be that
>the tests create generator-iterators in global variables.  With a bit of
>effort, I've been able to stomp most of the cycles.