Diez B. Roggisch wrote:
> Jean-Paul Calderone wrote:
>
>> On Tue, 22 Jan 2008 15:15:43 +0100, "Diez B. Roggisch"
>> <[EMAIL PROTECTED]> wrote:
>>> Jean-Paul Calderone wrote:
>>>
>>>> On Tue, 22 Jan 2008 14:20:35 +0100, "Diez B. Roggisch"
>>>> <[EMAIL PROTECTED]> wrote:
>>>>> For a simple greenlet/tasklet/microthreading experiment I found myself
>>>>> in the need to ask the question
>>>>>
>>>>> [snip]
>>>> Why do you need a special case for generators? If you just pass the
>>>> object in question to iter(), instead, then you'll either get back
>>>> something that you can iterate over, or you'll get an exception for
>>>> things that aren't iterable.
>>> Because - as I said - I'm working on a micro-thread thingy, where the
>>> scheduler needs to push returned generators to a stack and execute them.
>>> Using send(), which rules out iter() anyway.
>> Sorry, I still don't understand. Why is a generator different from any
>> other iterator?
>
> Because you can use send(value) on it for example. Which you can't with
> every other iterator. And that you can utizilize to create a little
> framework of co-routines or however you like to call it that will yield
> values when they want, or generators if they have nested co-routines the
> scheduler needs to keep track of and invoke after another.
So if you need the send() method, why not just check for that::
try:
obj.send
except AttributeError:
# not a generator-like object
else:
# is a generator-like object
Then anyone who wants to make an extended iterator and return it can
expect it to work just like a real generator would.
STeVe
--
http://mail.python.org/mailman/listinfo/python-list
