Please comment on Draft PEP for Enhanced Generators

[Kragen Sitaker]

"Raymond Hettinger" <othello at javanet.com> writes:

> http://users.javanet.com/~othello/download/genpep.htm
> 
> Please post your comments (and maybe a little encouragment) here on
> comp.lang.py or email them directly to me.

Good work.  Here are my comments, which (not surprisingly) focus on
the things I don't like rather than the things I do.

xfilter, xmap, etc., should take iterables, not sequences, as
arguments.

map and zip have weird different semantics when their sequence
arguments are of different lengths; xmap and xzip should conform to
these same weird semantics.  The comments in the specification say
they do, but the code says they don't.  There's a note explaining
this, but instead there should be correct code.  The justification
given for the difference in behavior, that it will produce infinite
sequences less often, is very weak.

xfilter, xmap, etc., don't need to be written up in a PEP; they can be
provided in a library.  MetaPy.Iterate already has
backward-compatible-to-1.5.2 versions of them, under more verbose
names, and others have written these as well.  It would be very nice
to have this in the standard library instead of in an extra package,
but they don't need to be builtins.  (Eventually making them builtins
might make programs that use them faster, though.)

The example of generator comprehensions says:
    if len(line) > 5:
        yield line
It should instead say:
    if len(line) > 5:
        yield (len(line),line)

There should be no subtle differences in behavior between generator
comprehensions and list comprehensions.  There should be no subtle
differences in behavior in a programming language, period.  The
current scoping behavior of list comprehensions is unforgivably
stupid, but having new language constructs behave subtly differently
from existing ones is worse.

I am in favor of the x = [yield y ...] generator comprehension syntax;
mostly I'm in favor of *some* generator comprehension syntax, and this
is the best one I've seen so far, but I hope we can come up with a
syntax that won't pose as many problems to learning Python as this one
does.

The two-way generator parameter passing proposal is incompletely
specified.  It apparently introduces invisible FIFOs; it doesn't
accomplish anything that can't be done more easily by passing an
iterator as an argument when constructing a generator; .throw() is
poorly named and it isn't clear why it's useful.  It should be
separated from the rest of the PEP and put into its own PEP so we can
discuss it separately; I think I would oppose it.

Return without an argument is not now considered weak design, at least
not in any discussion I ever read on the matter.  Return without an
argument in a function with a meaningful return value is almost
universally considered weak design.