On Friday 17 October 2003 07:15 pm, Guido van Rossum wrote:
But, indexing does stretch quite far in the current Python syntax and semantics (in Python's *pragmatics* you're supposed to use it far more restrainedly).
Which is why I didn't like the 'sum[x for x in S]' notation much.
Let it rest in peace, then.
Let's look for an in-line generator notation instead. I like
sum((yield x for x in S))
So do I, _with_ the mandatory extra parentheses and all, and in fact I think it might be even clearer with the extra colon that Phil had mentioned, i.e. sum((yield: x for x in S))
but perhaps we can make this work:
sum(x for x in S)
Perhaps the parser can be coerced to make this work, but the mandatory parentheses, the yield keyword, and possibly the colon, too, may all help, it seems to me, in making this syntax stand out more. Yes, some uses may "read" more naturally with as little extras as feasible, notably [examples that might be better done with list comprehensions except for _looks_...]: even_digits = Set(x for x in range(0, 10) if x%2==0) versus even_digits = Set((yield: x for x in range(0, 10) if x%2==0)) but that may be because the former notation leads back to the "set comprehensions" that list comprehensions were originally derived from. I don't think it's that clear in other cases which have nothing to do with sets, such as, e.g., Peter Norvig's original examples of "accumulator displays". And as soon as you consider the notation being used in any situation EXCEPT as the ONLY argument in a call...: foo(x, y for y in glab for x in blag) yes, I know this passes ONE x and one iterator, because to pass one iterator of pairs one would have to write foo((x, y) for y in glab for x in blag) but the distinction between the two seems quite error prone to me. BTW, semantically, it WOULD be OK for these iterator comprehension to NOT "leak" their control variables to the surrounding scope, right...? I do consider the fact that list comprehensions "leak" that way a misfeature, and keep waiting for some fanatic of assignment-as-expression to use it IN EARNEST, e.g., to code his or her desired "while c=beep(): boop(c)", use while [c for c in [beep()] if c]: boop(c) ...:-). Anyway, back to the subject, those calls to foo seem very error-prone, while: foo(x, (yield: y for y in glab for x in blag)) (mandatory extra parentheses, 'yield', and colon) seems far less likely to cause any such error. Alex