[Stackless] channels and StopIteration

[Kristján Valur Jónsson]

Actually, I think I'll use tasklet.send_throw() which jives with generator.throw().  I can reuse code from that.
K

> -----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
> feature?
> 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
> extendable.
> I'm proposing to use send_raise(), so that we might add receive_raise() too,
> should it be deemed convenient.
> 
> K
> 
> > -----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
> http://www.stackless.com/mailman/listinfo/stackless