On 10 August 2017 at 00:54, Nick Coghlan <ncogh...@gmail.com> wrote: > Yeah, if we ever did add something like this, I suspect a translation > using takewhile would potentially be easier for at least some users to > understand than the one to a break condition: > > {x for x in itertools.count(0) if 1000 <= x while x < 1000000} > > <=> > > x = set() > for x in itertools.count(0): > if 1000 <= x: > set.add(x) > # If you've never used the loop-and-a-half idiom, it's > # not obvious why "while <expr>" means "if not <expr>: break" > if not x < 1000000: > break > > is roughly > > {x for x in itertools.takewhile(itertools.count(0), lambda x: x < > 1000000) if 1000 <= x} > > <=> > > x = set() > for x in takewhile(itertools.count(0), lambda x: x < 1000000): > if 1000 <= x: > set.add(x)

## Advertising

Ugh, this discrepancy is worse than I thought, since the translation with that clause order is actually wrong (Terry mentioned this by pointing out that the proposed syntactic translation implemented "do...while" ordering). The takewhile example is also wrong, since it has the arguments in the wrong order. Fixing both of those issues gives the comparison: {x for x in itertools.count(0) while x < 1000000 if 1000 <= x} <=> x = set() for x in itertools.count(0): # If you've never used the loop-and-a-half idiom, it's # not obvious why "while <expr>" means "if <expr>: <loop body> else: break" if x < 1000000: if 1000 <= x: set.add(x) else: break is roughly: {x for x in itertools.takewhile(lambda x: x < 1000000, itertools.count(0)) if 1000 <= x} <=> x = set() for x in takewhile(lambda x: x < 1000000, itertools.count(0)): if 1000 <= x: set.add(x) And I think that gets me back to pretty much where I was the last time this came up: a while clause in comprehensions really only makes sense in combination with a while clause on for loops, where: for x in itertools.count(0) while x < 1000000: ... was roughly equivalent to: for x in itertools.count(0): if x < 1000000: ... else: <loop else clause, if any, still runs here> break (such that there's only one loop from the point of view of break/continue/else, but the loop may terminate based on either exhaustion of the underlying iterator *or* some specific condition becoming false) While I do think such a clause would be more readable for more people than the dropwhile/takewhile equivalents (especially when the latter end up needing to use lambda expressions), I'm still dubious that these cases come up often enough to justify the addition of a for-while loop as a composite construct (the old "dropwhile and takewhile aren't even common enough to justify being builtins, why should they jump all the way to syntactic support?" question applies). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/