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. 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() Diez -- http://mail.python.org/mailman/listinfo/python-list
