isgenerator(...) - anywhere to be found?

[Steven Bethard]

Diez B. Roggisch wrote:
> Jean-Paul Calderone wrote:
> 
>> On Tue, 22 Jan 2008 15:15:43 +0100, "Diez B. Roggisch"
>> <deets at nospam.web.de> wrote:
>>> Jean-Paul Calderone wrote:
>>>
>>>> On Tue, 22 Jan 2008 14:20:35 +0100, "Diez B. Roggisch"
>>>> <deets at nospam.web.de> 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