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
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
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
have
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 ineligible
for cyclic
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).
Does this mean that
[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
[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
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
[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 finally
[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 references the
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
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):
|..
[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
[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 cycle
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
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(). If
[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
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 that
[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 its
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()'.
Maybe, but
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:
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 change
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 PEP
[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 http://python.net/~goodger
24 matches
Mail list logo
