[Python-Dev] accumulator display syntax

[Alex Martelli]

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