«

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

Jean-Paul

Jean-Paul Calderone wrote:

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

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

-----Original Message-----
From: python-list-bounces+dhwani006=
[mailtoython-list-bounces+dhwani006=] On Behalf Of
Diez B. Roggisch
Sent: 22 January 2008 20:22
To: python-
Subject: Re: isgenerator(...) - anywhere to be found?

Jean-Paul Calderone wrote:

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