[Stackless] channels and StopIteration

[Kristján Valur Jónsson]

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