[Python-Dev] Re: accumulator display syntax
Skip Montanaro
skip at pobox.com
Fri Oct 17 16:56:01 EDT 2003
>>> sum((yield x for x in S))
>>>
>>> but perhaps we can make this work:
>>>
>>> sum(x for x in S)
Paul> I like the look of this. In this context, it looks very natural.
How would it look if you used the optional start arg to sum()? Would either
of these work?
sum(x for x in S, start=5)
sum(x for x in S, 5)
or would you have to parenthesize the first arg?
sum((x for x in S), start=5)
sum((x for x in S), 5)
Again, why parens? Why not
sum(<x for x in S>, start=5)
sum(<x for x in S>, 5)
or something similar?
Also,
sum(x for x in S)
and
sum([x for x in S])
look very similar. I don't think it would be obvious to the casual observer
what the difference between them was or why the first form didn't raise a
SyntaxError.
>> It's a little clearer with parentheses, of course, so perhaps they
>> should be required:
>>
>> for x in (y*2 for y in z if y<20):
>> ...
Paul> I'd rather not require parentheses in general.
Parens are required in certain situations within list comprehensions around
tuples (probably for syntactic reasons, but perhaps to aid the reader as
well) where tuples can often be defined without enclosing parens. Here's a
contrived example:
>>> [(a,b) for (a,b) in zip(range(5), range(10))]
[(0, 0), (1, 1), (2, 2), (3, 3), (4, 4)]
>>> [a,b for (a,b) in zip(range(5), range(10))]
File "<stdin>", line 1
[a,b for (a,b) in zip(range(5), range(10))]
^
SyntaxError: invalid syntax
Paul> Guido's example of sum(x for x in S) looks too nice for me to want
Paul> to give it up without a fight. But I'm happy to have cases where
Paul> the syntax is ambiguous, or even out-and-out unparseable, without
Paul> the parentheses. Whether it's possible to express this in a way
Paul> that Python's grammar can deal with, I don't know.
I rather suspect parens would be required for tuples if they were added to
the language today. I see no reason to make an exception here.
Skip
More information about the Python-Dev
mailing list