Please comment on PEP XXX: Enhanced Generators

Don O'Donnell donod at home.com
Thu Jan 31 17:47:27 EST 2002


Raymond Hettinger wrote:
> 
> I have updated the draft PEP summarizing proposed enhancements to
> generators:
> http://users.javanet.com/~othello/download/genpep.htm
> 
[...]
> 
> Please post your comments on the new draft here on comp.lang.py or email
> them directly to me.

Very nice work.  The x*** functions would be great to have, although I
wouldn't be heart broken if they don't get into the builtins, since I
could write a module to do those myself. But it sure would be nice to
not have to maintain them myself.

The generator comprehension, OTOH, makes a lot of sense as a logical
extension to the language in view of the addition of
iterators/generators to the language.

On the issue of 'to bracket or not to bracket' gen comps:

I believe the [brackets] should be kept for the following reasons:

1.   Brackets make the syntax clearer and easier to read.

2.   Brackets indicate that it _is_ a sort of lazy or virtual list, in
the sense that it can be used in the same way as a list in a 'for'
statement, similar to the xrange(...) function call.  

However, this argument looses some potency now that xrange() has been
stripped of most of its list-like attributes, and we now have a new
language concept (generators).  We should start thinking of xrange() as
a generator (new language concept) rather than a list.


Minor typo here:

"""
    The next steps in the evolution of generators are:

    1. Add built-in functions which provide lazy alternatives to their
       complete evaluation counterparts and one other convenience
       function which was made possible once iterators and generators
       became available.  The new functions are xzip, xmap, xfilter,
       and index.
"""
           ^^^^^----> change to indexed

As for two-way generator parameter passing I am neutral, I don't see any
real need for it, but I'm sure some people will find it useful. 

My only objection is in requiring the function to perform differently
depending on whether or not the 'yield' keyword appears on the right
side of an assignment:

"""
    Note D:  There is a difference in the implementation of .submit() as
    compared to .next().  Here's the normal flow using .next():

        g = mygen(p1) will bind p1 to a local variable and then return a
                generator to be bound to g
[...]
    In contrast, the flow using .submit() is different:

        g = mygen(p1) will bind p1 to a local variable and then
IMMEDIATELY
               executes code within mygen() until a yield is encountered
               then it suspends excution and returns a generator to be
               bound to g
"""

And what if there is more than one 'yield' in a generator def, some
being assigned to a variable and some not?  Would the 'g.next()' and
'g.submit(val)' calls have to be synchronized with the 'yield val' and
'val = yield None' statements?  Seems awfully messy and error prone to
me.  But I haven't thought about it long enough to suggest a better
way.  If I do, I will let you know.

Good luck with the PEP.

Don



More information about the Python-list mailing list