[Python-Dev] comprehension abbreviation (was: Adding any() andall())

Raymond Hettinger python at rcn.com
Mon Mar 14 02:11:03 CET 2005

> > - Before anybody asks, I really do think the reason this is
> > at all is really just to save typing; there isn't the "avoid double
> > evaluation" argument that helped acceptance for assignment operators
> > (+= etc.), and I find redability is actually improved with 'for'.

{Neil Hodgson]
>    For me, the main motivation is to drop an unnecessarily repeated
> identifier. If you repeat something there is a chance that one of the
> occurrances will be wrong which is one reason behind the Don't Repeat
> Yourself principle.

It's not actually a repetition.  Instead, it is a precise expression of
what is to be returned.  The proposal adopts a custom syntax to handle
one possible return value (identity) as a default.  You're trading away
explictness, giving up on having a uniform syntax, and introducing more
than one way to do it (the current approach would still be valid).

The repeated expression argument carried more weight in the context of
augmented assignment where complex lvalues are common:  self.arr[i] +=
j.  For genexps and listcomps, simple loop variables are the norm.

Try applying the proposal to existing code.  I think you'll see that
you've gained nothing.

> The reader can more readily see that this is a
> filter expression rather than a transforming expression.

Personally, I find the proposed syntax to be difficult to parse.  It's a
step backwards.


Sorry, I deem the proposal to be horrendous and hope it gets trounced
before it gets out of hand.


More information about the Python-Dev mailing list