Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

[Phillip J. Eby] > Now you've shaken my faith in Uncle Timmy. :) Now, now, a mere technical matter is no cause for soul-damning heresy! > Seriously, he did *say*: > > """For example, it doesn't know the difference between an object > that's in a trash cycle, and an object that's not in a trash

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

[Phillip J. Eby] > ... > However, Tim's new post brings up a different issue: if the collector can't > tell the difference between a cycle participant and an object that's only > reachable from a cycle, then the mere existence of a generator __del__ will > prevent the cycle collection of the entire

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

At 07:18 PM 5/19/2005 +0100, Michael Hudson wrote: >"Phillip J. Eby" <[EMAIL PROTECTED]> writes: > > > However, Tim's new post brings up a different issue: if the collector > can't > > tell the difference between a cycle participant and an object that's only > > reachable from a cycle, > >Uh, that

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

"Phillip J. Eby" <[EMAIL PROTECTED]> writes: > However, Tim's new post brings up a different issue: if the collector can't > tell the difference between a cycle participant and an object that's only > reachable from a cycle, Uh, that's not what he meant: />> class C: |.. def __del__(self): |.

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

At 10:48 AM 5/19/2005 -0700, Guido van Rossum wrote: >Hm. The way I see it, as soon as a generator raises an exception, its >frame is part of a cycle: the frame's f_exc_traceback points to the >traceback object, and the traceback object's tb_frame points back to >the frame. So that's a cycle right

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

[Phillip J. Eby] > >Throwing an exception also provides ample opportunity for creating > >cycles, since the frame hold a reference to the most recent traceback. > >Ironically, throwing an exception with a traceback into a generator is > >likely to cause a cycle because the traceback likely referenc

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

[Guido] > ... > 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 fin

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

At 10:09 AM 5/19/2005 -0700, Guido van Rossum wrote: >[Phillip J. Eby]the only way a generator-iterator can become > > part of a cycle is via an action taken outside the generator. (E.g. > > passing it into itself via 'continue', creating a link from one of its > > arguments to it, etc.) So, it'

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325:generator exceptions and cleanup

> 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). Raymon

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

[Phillip J. Eby]the only way a generator-iterator can become > part of a cycle is via an action taken outside the generator. (E.g. > passing it into itself via 'continue', creating a link from one of its > arguments to it, etc.) So, it's probably not a terrible limitation in > practice. It's en

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

[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 becaus

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

At 12:36 PM 5/19/2005 -0400, James Y Knight wrote: >On May 19, 2005, at 8:43 AM, Phillip J. Eby wrote: >>At 06:09 PM 5/19/2005 +1200, Greg Ewing wrote: >>>Guido van Rossum wrote: - When a generator is GC'ed, its close() method is called (which is a no-op if it is already closed). >>> >>

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

On May 19, 2005, at 8:43 AM, Phillip J. Eby wrote: > At 06:09 PM 5/19/2005 +1200, Greg Ewing wrote: >> Guido van Rossum wrote: >>> - When a generator is GC'ed, its close() method is called (which >>> is a >>> no-op if it is already closed). >> >> Does this mean that all generators will be ineligi

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

At 06:09 PM 5/19/2005 +1200, Greg Ewing wrote: >Guido van Rossum wrote: > > > - When a generator is GC'ed, its close() method is called (which is a > > no-op if it is already closed). > >Does this mean that all generators will be ineligible >for cyclic garbage collection (since they implicitly >hav

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

Guido van Rossum wrote: > I believe that in the discussion about PEP 343 vs. Nick's PEP 3XX > (http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html, still > awaiting PEP moderator approval I believe?) It turns out my submission email took the scenic route, and I wasn't using a proper text ed

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

Guido van Rossum wrote: > - When a generator is GC'ed, its close() method is called (which is a > no-op if it is already closed). Does this mean that all generators will be ineligible for cyclic garbage collection (since they implicitly have something equivalent to a __del__ method)? Other than

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

[Guido van Rossum] > I believe that in the discussion about PEP 343 vs. Nick's PEP 3XX > (http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html, still > awaiting PEP moderator approval I believe?) ... Nick hasn't submitted it for a PEP number yet. -- David Goodger

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325:generator exceptions and cleanup

> > So at this point it seems your proposal is just nailing down specifics > for > > the open parts of PEP 325. > > Or PEP 288? That has throw() (albeit with a different signature). I > could do without the attributes though (PEP 342 provides a much better > solution IMO). > > If either of those

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

At 01:28 PM 5/18/2005 -0400, Raymond Hettinger wrote: > > Okay. Maybe we should just update PEP 325, then? > >-1. > >Keep this separate. Have you read PEP 325 lately? Mostly the change would consist of deleting rejected options or moving them to a rejected options section. The only other chan

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

> Okay. Maybe we should just update PEP 325, then? -1. Keep this separate. Raymond ___ 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/ar

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325:generator exceptions and cleanup

> > Should this maybe just be added to PEP 342? To me, PEP 342 has always > > seemed incomplete without ways to throw() and close(), but that could > > easily be just me. In any case I'd expect the implementation of > > 'next(arg)' to have some overlap with the implementation of 'throw()'. > > M

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

[Phillip J. Eby] > Okay. Maybe we should just update PEP 325, then? It has much of the stuff > that we'd want in the new PEP, such as the rationale. Your new proposal, > AFAICT, is just a simple extension of the PEP 325 protocol (i.e., adding > 'throw()'), along with some decisions to resolve it

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

At 09:55 AM 5/18/2005 -0700, Guido van Rossum wrote: >[Phillip J. Eby] > > And there was much rejoicing in the land of the co-routiney > people. :) +1000. > > > > Should this maybe just be added to PEP 342? To me, PEP 342 has always > > seemed incomplete without ways to throw() and close(), but

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

[Phillip J. Eby] > And there was much rejoicing in the land of the co-routiney people. :) > +1000. > > Should this maybe just be added to PEP 342? To me, PEP 342 has always > seemed incomplete without ways to throw() and close(), but that could > easily be just me. In any case I'd expect the

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

On Wednesday 18 May 2005 17:39, Guido van Rossum wrote: > I believe that in the discussion about PEP 343 vs. Nick's PEP 3XX > (http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html, still > awaiting PEP moderator approval I believe?) the main difference is > that Nick proposes a way to inject a

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

At 09:39 AM 5/18/2005 -0700, Guido van Rossum wrote: >- g.throw(type, value, traceback) causes the specified exception to be >thrown at the place where the generator g is currently suspended. If >the generator catches the exception and yields another value, that is >the return value of g.throw(). I

[Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

I believe that in the discussion about PEP 343 vs. Nick's PEP 3XX (http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html, still awaiting PEP moderator approval I believe?) the main difference is that Nick proposes a way to inject an exception into a generator; and I've said a few times that I l