[Stackless] Stackless API

Oren Tirosh oren-slp at hishome.net
Mon Feb 2 21:13:45 CET 2004

On Mon, Feb 02, 2004 at 02:13:05PM -0500, Bob Ippolito wrote:A
> 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).

All Python builtins support iteration if it makes sense in some way 
for that type. I think channels should, too. Users would expect to be 
able to write something like "for item in channel".

You don't have to rename - add a next() method as a synonym for receive. 
Just like in Python 2.3 a file object's next() method is more-or-less a 
synonym for readline().

> 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.

An easy way to implement that is to create an internal wrapper object for 
exceptions.  An instance of this wrapper will be created by send_exception() 
and receive() will check if the object is an instance of this type. Sending 
an exception will be slightly slowed down by creating the wrapper object but 
the more critical path of receiving will actually be faster: a call to 
PyObject_IsInstance can be replaced with a direct test of result->ob_type 
because the wrapper is not subclassable. In fact, it's never visible to 
Python code.

The wrapper could also carry an optional traceback. Existing code that uses 
send() and send_exception() consistently should continue to work with no 


Stackless mailing list
Stackless at stackless.com

More information about the Stackless mailing list