PEP 289: Generator Expressions (please comment)
aleax at aleax.it
Mon Oct 27 15:03:16 CET 2003
Werner Schiendl wrote:
> personally the parentheses seem a little strange to me, or put another
> way, I feel that simple parentheses around "everything" should not
> change the meaning of the code.
> As the code shows, just putting parentheses around the value 5 doesn't
> make it a tuple.
No, but, in all cases where the lack of parentheses would make the
syntax unclear, you do need parentheses even today to denote tuples.
a list of three items, versus a list of one tuple.
> Maybe an alternative would be to have similar to tuples:
The PEP *IS* "similar to tuples": parentheses are mandatory around a
generator expression wherever their lack would make things unclear
(and that's basically everywhere, except where the genexp is the
only argument to a function call). Hard to imagine a simpler rule.
The idea of "adding a comma" like this:
> [x for x in y, ] # List containing generator
feels totally arbitrary and ad-hoc to me, since there is NO other
natural connection between genexps and commas (quite differently
from tuples). Moreover, it would not help in the least in other
VERY similar and typical cases, e.g.:
[x for x in y, z,] # ok, now what...?
today this means [y, z]. Would you break backwards compatibility
by having it mean a [<genexp>] instead? Or asking for a SECOND
trailing comma to indicate the latter? And what about a genexp
followed by z, and, ... ?
No, really, this whole "trailing comma to indicate a genexp in one
very special case" idea is sort of insane. Compare with:
[x for x in y, z,] # same as [y, z]
[(x for x in y, z,)] # the [<genexp>] case
[(x for x in y), z,] # the [<genexp>, z] case
what could possibly be clearer? Not to mention the parens rule
is simple, universally applicable, breaks no backwards compat,
AND is far closer to the general case for tuples ("parens when
needed for clarity") than the "singleton tuple" case you seem
to have focused on.
More information about the Python-list