[Stackless] Stackless API

[Christian Tismer]

Oren Tirosh wrote:

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

Next is planned since a long time, the same issue as
closing, stopiteration and such. This is not a real
change.
And I have to say, I liked your little shuffling which
creates other patterns so easily.

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

This is what I didn't understand.
Travel when, and how?
At the moment, exceptions are like
data that explodes. I agree to split
implementations of send and send_exception,
but I still don't see what the desired behavior
is, exactly.

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

This is one of the rare cases that *I* don't want
to think of implementations, but find out about
semantics. :-)

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

Getting even more confused:
When exactly is your exception raised, and where?
Are you describing what is there today in a
split implementation, extended by the
ability to "redirect" an existing exception, including
traceback?  (If so then I understood :-)

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/

_______________________________________________
Stackless mailing list
Stackless at stackless.com
http://www.stackless.com/mailman/listinfo/stackless