[Stackless] Stackless API
tismer at stackless.com
Mon Feb 2 21:27:10 CET 2004
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
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
> 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
> The wrapper could also carry an optional traceback. Existing code that uses
> send() and send_exception() consistently should continue to work with no
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
More information about the Stackless