That First Next Argument

Axel Rauschmayer axel at
Wed Aug 20 10:04:17 PDT 2014

Isn’t the problem that a generator function contains the code for both generator object creation and generator behavior? Normally, this is convenient, because both parts can share an environment. But for Kevin’s use case, it becomes a problem.

One possibility may be to implement this as a tool class, separating the concerns “construction” and “behavior”:

class MyGenerator extends CustomGenerator {
    constructor(/* args for generator object creation */) {
    * behavior(firstArgOfNext) {

On Aug 20, 2014, at 18:43 , Brendan Eich <brendan at> wrote:

> Andy Wingo wrote:
>> On Wed 20 Aug 2014 16:41, Kevin Smith<zenparsing at>  writes:
>>> >  I'm still curious why we need to go through such exercises, though. It
>>> >  seems clear to me that this is a weakness of the current design, and
>>> >  would be easily addressed with syntax. Is there a back-story that I'm
>>> >  not aware of?
>> No backstory that I'm aware of -- only something that doesn't really
>> fall out from the generators design.  There's just no sensible name you
>> could give the value (without getting "creative" with lexical scope),
>> and no continuation waiting to receive it.
> Right. Anyone know whether this has come up as a PEP or suggestion on python-dev?
> The meeting notes Kevin cited in the thread root don't mention it, but IIRC we did briefly talk about syntax that could be added in a future edition (AKA next year in a spec, next month in a browser implementation) for receiving that first-next value:
> function* gen(a, b, c) first {
>  ...
> }
> Not bikeshedding, some found it ugly or too terse, many wondered about other future syntax vying to go after the parameter list. But the idea seems good.
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at

Dr. Axel Rauschmayer
axel at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list