[Python-Dev] Implementing PEP 342 (was Re: Withdrawn PEP 288 and thoughts on PEP 342)

[Phillip J. Eby]

At 04:55 PM 6/18/2005 +0300, Oren Tirosh wrote:
>On 6/18/05, Phillip J. Eby <pje at 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.