I would like to believe that "break"-as-a-expression solves most of these issues.  It is reasonable, though, to drop the "return"-as-an-expression part of the proposal, because you need to know that the comprehension is run in a separate function to understand it (it's a bit ironic that I am dropping the original proposal to defend my own, now...).


((x, y) for x in l1 if f1(x) or break for y in l2 if f2(y) or break)

This maps directly to

for x in l1:
    if f1(x) or break:
        for y in l2:
            if f2(y) or break:
                yield x, y

which is literally a copy-paste of the second part followed by yielding the first part.  I think this reads reasonably well but this is obviously a subjective issue.


2014-11-21 8:49 GMT-08:00 Chris Angelico <rosuav@gmail.com>:
On Sat, Nov 22, 2014 at 3:36 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
> On 11/21/2014 08:22 AM, Andrew Barnert wrote:
>> Maybe what we need to do is update PEP 3142, gathering all of the alternative ideas,
>> and expanding on the rationale, so Guido can reject that, and next time this comes
>> up, everyone will have something to read before having the same arguments about the
>> same proposals?
> Are we accepting nominations?  I have the perfect fellow in mind.  :)
> (And in case Chris decides to nominate me in retaliation, I decline. ;)

Heh! Great, I'm going to get a name for writing the PEPs that exist
solely to be rejected... I was hoping PEP 479 would be accepted
easily, given who was advocating it, but now it's starting to look
like I doomed the proposal :)

Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/