[Stackless] channels and StopIteration

Kristján Valur Jónsson kristjan at ccpgames.com
Fri May 25 13:02:53 CEST 2012


Hi richard.
I think you misunderstand.
The raised exception is indeed the same instance on the other side.  send_throw does not, in fact, build on send_exception but is an entirely new api.
It creates a bomb object using the passed in exception information.
The python api is designed to be similar to the generator.throw() function:

The manual says this:

generator.throw(type[, value[, traceback]])
Raises an exception of type type at the point where generator was paused, and returns the next value yielded by the generator function. If the generator exits without yielding another value, a StopIteration exception is raised. If the generator function does not catch the passed-in exception, or raises a different exception, then that exception propagates to the caller.

But the implementation is different, accepting the same kind of arguments as a ´raise' exception.
The implementation for channel_send_throw borrows the argument processing from generator_throw().

I've submitted a defect to bugs.python.org about correcting the generator.throw() docs.
http://bugs.python.org/issue14911




> -----Original Message-----
> From: stackless-bounces at stackless.com [mailto:stackless-
> bounces at stackless.com] On Behalf Of Richard Tew
> Sent: 25. maí 2012 03:54
> To: The Stackless Python Mailing List
> Subject: Re: [Stackless] channels and StopIteration
> 
> On Sat, Apr 14, 2012 at 12:00 AM, Kristján Valur Jónsson
> <kristjan at ccpgames.com> wrote:
> > Done, with unitests and all.
> 
> The change in general looks good except for two aspects that make me
> antsy.
> 
> The first is the API of the throw implementation.
> 
> http://hg.python.org/stackless/rev/d4b2e291fb48#l2.82
> 
> The way this accepts an existing exception instance as an argument..
> You can make something that looks like the thrown instance on the other
> side, sure, but it isn't the same as the thrown one.  I do not find it consistent
> and I would want the raised tasklet to be the one that was thrown, if I were
> throwing a specific instance of one.  If this isn't going to happen, then I'd
> want to know about it and get an exception should I try.  I'd insert a pithy
> phrase here about being sold some object and being told it is another, but I
> don't remember any :-)
> 
> The second is that this builds on the existing Stackless tasklet exception
> raising mechanism.  And that mechanism is very limited (specify a class and
> simple arguments).  If this is what we have to do, we have to do it I guess.
> But.. it adds to the burden of moving away from that system should we
> choose to do it at a future time. Is this the better way to go about this?
> 
> Cheers,
> Richard.
> 
> _______________________________________________
> Stackless mailing list
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless





More information about the Stackless mailing list