[Stackless] channels and StopIteration
Kristján Valur Jónsson
kristjan at ccpgames.com
Thu Apr 12 15:32:13 CEST 2012
Actually, I think I'll use tasklet.send_throw() which jives with generator.throw(). I can reuse code from that.
> -----Original Message-----
> From: stackless-bounces at stackless.com [mailto:stackless-
> bounces at stackless.com] On Behalf Of Kristján Valur Jónsson
> Sent: 12. apríl 2012 10:29
> To: The Stackless Python Mailing List
> Subject: Re: [Stackless] channels and StopIteration
> I don't know. How much code and how many people are actually using this
> Particularly closing from the receiving side, which is atypical, really.
> Anyway, this is the place to ask such questions.
> Also, have you seen my recent commits to the repo? A reference counting
> bug in shutdown, and extending 'atomic' to work across threads.
> Here, I´m also proposing a new channel method:
> channel.send_raise(exc=None, val=None, tb=None) The arguments have
> the same semantics as the arguments to the "raise" keywords, so that raising
> an exception instance is possible.
> One can also add a tuple from sys.exc_info(), or it will implicitly get the
> current exception if nothing is provided.
> The current send_exception takes a variable argument list and isn't
> I'm proposing to use send_raise(), so that we might add receive_raise() too,
> should it be deemed convenient.
> > -----Original Message-----
> > From: stackless-bounces at stackless.com [mailto:stackless-
> > bounces at stackless.com] On Behalf Of Richard Tew
> > Sent: 12. apríl 2012 03:18
> > To: The Stackless Python Mailing List
> > Subject: Re: [Stackless] channels and StopIteration
> > On Thu, Apr 12, 2012 at 1:49 AM, Kristján Valur Jónsson
> > <kristjan at ccpgames.com> wrote:
> > > Channels objey the iterator protocol. calling channel.close() will
> > > raise the StopIteration exception from the channel.__next__ method.
> > >
> > > But, calling channel.close() from the receiving end will also cause
> > > this same exception to be raised when someone wants to call
> > channel.send().
> > >
> > > Now, I wonder if a more appropriate exception for the send() call
> > > wouldn't be GeneratorExit()? This is what the generator
> > > yield(foo) statement raises when the generator is closed, and it
> > > seems logical that this should be the exception raised when someone
> > > tries to send to a
> > closed channel.
> > Let's say there is existing code out there that expects the old
> > behaviour, this would of course break that code. And on the other
> > hand, I'm not sure that something which is not a generator raising
> > generator-related exceptions is an appropriate change - but then we
> > could make a Stackless-specific subclass which was more specific.
> > Is breaking backwards compatibility worth the gain?
> > Cheers,
> > Richard.
> > _______________________________________________
> > Stackless mailing list
> > Stackless at stackless.com
> > http://www.stackless.com/mailman/listinfo/stackless
> Stackless mailing list
> Stackless at stackless.com
More information about the Stackless