isgenerator(...) - anywhere to be found?
Diez B. Roggisch
deets at nospam.web.de
Tue Jan 22 15:52:02 CET 2008
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
>>> 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.
I'm currently at work and can't show you the code - I don't claim that my
current approach is the shizzle, but so far it serves my purposes - and I
need a isgenerator()
More information about the Python-list