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 firstname.lastname@example.org:
On Sat, Nov 22, 2014 at 3:36 AM, Ethan Furman email@example.com 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
and expanding on the rationale, so Guido can reject that, and next time
up, everyone will have something to read before having the same
arguments about the
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 :)
ChrisA _______________________________________________ Python-ideas mailing list Pythonfirstname.lastname@example.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/