Sigh. Looks like Guido already used the time machine to bring up these
ideas five years ago:
http://mail.python.org/pipermail/python-dev/2000-March/002514.html
And apparently you went back with him:
http://mail.python.org/pipermail/python-dev/2000-March/002478.html
So I give up, 'caus
At 10:15 PM 6/18/2005 -0400, Phillip J. Eby wrote:
>Okay, I think I see why you can't do it. You could guarantee that all
>relevant __del__ methods get called, but it's bloody difficult to end up
>with only unreachable items in gc.garbage afterwards. I think gc would
>have to keep a new list for
At 06:50 PM 6/18/2005 -0600, Neil Schemenauer wrote:
>On Sat, Jun 18, 2005 at 06:24:48PM -0400, Phillip J. Eby wrote:
> > So, I think I've got this sorted out, assuming that I'm not doing
> > something hideously insane by having 'has_finalizer()' always
> > check tp_del even for non-heap types, and
On Sat, Jun 18, 2005 at 06:24:48PM -0400, Phillip J. Eby wrote:
> So, I think I've got this sorted out, assuming that I'm not doing
> something hideously insane by having 'has_finalizer()' always
> check tp_del even for non-heap types, and defining a tp_del slot
> for generators to call close() in.
One more note; I tried changing generators to set their gi_frame to None
whenever the generator finishes normally or with an error; this eliminated
most of the reference cycles, and I was able to make test_generators work
correctly with only 3 explicit close() calls, for the "fun" tests that use
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
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 t