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".