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

Discussion in 'Python' started by Jean-Paul Calderone, Jan 22, 2008.

  1. 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, Jan 22, 2008
    #1
    1. Advertising

  2. 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, Jan 22, 2008
    #2
    1. Advertising

  3. 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
    Steven Bethard, Jan 22, 2008
    #3
  4. UNSUBSCRIBE

    -----Original Message-----
    From: python-list-bounces+dhwani006=
    [mailto:python-list-bounces+dhwani006=] On Behalf Of
    Diez B. Roggisch
    Sent: 22 January 2008 20:22
    To:
    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
    TezZ Da Sp@cE MaN, Jan 23, 2008
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jason Shohet

    can't find the javascript cookie anywhere

    Jason Shohet, May 11, 2004, in forum: ASP .Net
    Replies:
    4
    Views:
    554
    Jason Shohet
    May 11, 2004
  2. =?Utf-8?B?U3RldmVuIFc=?=

    Selecting Rows by Clicking Anywhere

    =?Utf-8?B?U3RldmVuIFc=?=, Feb 15, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    356
    =?Utf-8?B?U3RldmVuIFc=?=
    Feb 15, 2005
  3. Fernando Lopes
    Replies:
    0
    Views:
    3,191
    Fernando Lopes
    Apr 28, 2005
  4. Paul W
    Replies:
    4
    Views:
    4,665
    Daniel Walzenbach
    Jul 15, 2005
  5. Diez B. Roggisch

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

    Diez B. Roggisch, Jan 22, 2008, in forum: Python
    Replies:
    6
    Views:
    368
Loading...

Share This Page