On 11 August 2017 at 06:53, Spencer Brown <spencer...@live.com> wrote: > The logical solution to me is to allow any order of while and if, and follow > the same 'rule' as multiple for loops - just nest/test those in that order. > Then you can have whatever priority you need. One question though is how > this should handle multiple loops - break all of them, or just the current > one?
This is why I think a for-while construct in comprehensions would really only make sense in combination with a *statement* level for-while construct, as the problem we have is: - a termination condition can't readily use "if" (even in combination with "break") because that's visually and syntactically ambiguous with a filter condition - a naive translation of a "while" based syntax makes it look like a nested *non-terminating* loop Both of those problems may be resolved if a "for-while" loop exists as a top level looping construct that can terminate based on *either* an iterator being exhausted *or* a condition becoming false. The question then becomes whether or not a "for-while" loop is actually useful enough to be added as a general construct, given that we already have "if not condition: break" as a way of modeling a loop ending early because a condition became false. One way to gather evidence on that front would be to survey the standard library for places where we use "break", and see if any of them would be more readable given a for-while construct, whether as a statement, or as part of the comprehension syntax. (Note: I'm not interested enough in the idea to do that evidence gathering myself, I'm just pointing it out in case anyone is curious enough to take the time to collect those details) 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/