At 04:55 PM 6/18/2005 +0300, Oren Tirosh wrote:

On 6/18/05, Phillip J. Eby <pje@telecommunity.com> wrote:

...

At 08:03 PM 6/16/2005 -0700, Guido van Rossum wrote: It turns out that making 'next(EXPR)' work is a bit tricky; I was going to use METH_COEXIST and METH_VARARGS, but then it occurred to me that METH_VARARGS adds overhead to normal Python calls to 'next()', so I implemented a separate 'send(EXPR)' method instead, and left 'next()' a no-argument call.

Please use the name "feed", not "send". That would make the enhanced generators already compatible "out of the box" with existing code expecting the de-facto consumer interface (see http://effbot.org/zone/consumer.htm). The other part of the consumer interface (the close() method) is already being added in PEP 343.

Hm. Do you want reset() as well? :) More seriously, I'm not sure that PEP 343's close() does something desirable for the consumer interface. Overall, this sounds like something that should be added to the PEPs though. I hadn't really thought of using inbound generator communication for parsing; it's an interesting use case. However, looking more closely at the consumer interface, it seems to me the desired semantics for feed() are different than for send(), because of the "just-started generator can't receive data" problem. Also, the consumer interface doesn't include handling for StopIteration. Maybe feed() should prime the generator if it's just started, and throw away the yield result as long as it's None? Maybe it should ignore StopIteration? Perhaps it should raise an error if the generator yields anything but None in response? These seem like questions worth discussing.