[Stackless] Stackless API

Bob Ippolito bob at redivi.com
Mon Feb 2 20:13:05 CET 2004

On Feb 2, 2004, at 1:49 PM, Oren Tirosh wrote:

> On Mon, Feb 02, 2004 at 05:56:46PM +0100, Christian Tismer wrote:
>> Oren Tirosh wrote:
>>> On Thu, Jan 29, 2004 at 08:57:27PM +0100, Christian Tismer wrote:
>>> ...
>>>> As we are at it:
>>>> What I *want* to take out is support for sending
>>>> exceptions to channels.
>>> There is one use case I found very useful: sending StopIteration 
>>> into the
>>> channel. I'm +1 on removing support for sending exceptions to 
>>> channels
>>> but only if there is some alternative mechanism to signal "end of 
>>> data".
>>> Perhaps channel.close() ?
>> channel.close() is definately on my todo list.
> If you just change "send" to "feed" and add the "close" method you get 
> the
> consumer protocol:
>     http://effbot.org/zone/consumer.htm
> If you change "receive" to "next" and add StopIteration (triggered by
> close on the remote side) you get the iterator protocol:
>     http://www.python.org/doc/current/lib/typeiter.html
> This would make it possible to use channels in contexts that never 
> heard
> of stackless and just use standard data source and data sink protocols.
> This, of course, raises other issues like compatibilty with existing 
> code.

Personally I'm -1 on renaming things.  If you want compatibility with 
existing code, don't change the semantics of stackless.  Instead, make 
a channel-wrapper or subclass that adopts the particular interface that 
you want (consumer, generator, semaphore, whatever).

I think that exceptions on channels are more useful than just closure 
notification, but I think the implementation should be changed to make 
these exceptions travel out-of-band from the data.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
URL: <http://www.stackless.com/pipermail/stackless/attachments/20040202/fd422274/attachment.bin>
-------------- next part --------------
Stackless mailing list
Stackless at stackless.com

More information about the Stackless mailing list