[Python-ideas] Accessing the result of comprehension's expression from the conditional

[Stephen J. Turnbull]

Lie Ryan writes:

 > The regular map+filter is still available by not using the `as` keyword
 > (or by not calling F). Thus when what you really wanted is two maps, you
 > need to use two comprehensions. The number of maps should == The number
 > of comprehension; currently it is not always possible to do so, when the
 > assumed map and filter ordering doesn't match our required ordering.

I understand that; the first part is a trivial consequence of backward
compatibility, and the second you've been at pains to explain already.
I'm not trying to say you're *wrong*.  The appeal of the proposed
syntax in the particular case is obvious.

Admittedly, I personally don't find it particularly useful.  I don't
have any problem at all with decomposing what you consider to be a
single comprehension into a pipeline of generators.  It's efficient
and elegant, and it's not clear to me that your construct can generate
better byte code than Ben's nested comprehensions.  If not, your claim
that "this is conceptually a single comprehension, why break it into
two or more" seems to me to be founded on quicksand.  But that's
beside the point, I don't have to like all the constructs that other
people find useful.  Even Guido has allowed things into Python that he
personally dislikes quite a bit.

I'm saying it's my impression that it will be *insufficient*.  It's
like if somebody suggested introducing a unary operator "**" to denote
"squared".  That's just not useful enough, while a *binary* operator
"**" for "power" is useful enough to have been added ages ago.

In other words, that kind of logic hasn't been able to justify
*proliferation* of syntax in the more than 5 years I've been following
Python-Dev (and now Python-Ideas).  It only works when the new syntax
is sufficiently comprehensive to replace "all the old uglies" in some
sense.  Even if you can't clear the hurdle in one bound, you need to
aim at something like "getting rid of *all* lambda/external function
definitions in comprehensions".