Thanks. How do I go explore the archives? I think the spirit of this is along the following line:
for(int i = 0; (cond); i++) ... Is a common way to a express a loop breaking out once a condition is not met, as is true for: while cond But there is no way to express (in terse fashion) a loop in which a condition is true but does not break if it is not satisfied. That's normally expressed by nesting an 'if' statement but by doing this, the 'for' and 'if' appear as separate when really the 'if' could be considered as part of the definition of the loop itself. On Fri, Apr 10, 2020, 4:19 PM Chris Angelico <[email protected]> wrote: > On Sat, Apr 11, 2020 at 7:06 AM Elliott Dehnbostel > <[email protected]> wrote: > > > > (meant to reply to the thread here so I'll send it again) > > > > Thanks everyone for the input. I used a trivial example where the inside > is a single, simple expression (which can be refactored in many different, > clever ways) but the idea was that more complicated blocks could not be > (easily) refactored in similar ways. Additionally, there may be further > nested loops inside, each having their own conditions -- creating a > twice-nested overhead for each one, rapidly becoming gross. > > > > This is "special" because it reduces the nesting overhead of conditioned > loops from 2 to 1, which is especially important if you've got several > nested loops: > > > > for a in A: > > if cond_a: > > for b in B: > > if cond_b: > > > > # code block > > > > > > then becomes: > > > > for a in A if cond_a: > > for b in B if cond_b: > > # code block > > > > you could even do: > > > > for a, b in zip(A,B) if cond_a and cond_b: > > # code block > > > > Either option I feel is far more suitable than the first example. > > > > If you'd like me to use a better demonstrative example, let me know. > > > > As a side point, this isn't what most people will think of when you > say "loop invariants". This would be better described as a "filtered > loop". > > It's something that's been suggested/requested periodically. You may > want to search the archives to see what's been said before. > > Personally, I would quite like this, but the benefit is fairly > marginal, so there's usually a fair amount of pushback. > > ChrisA > _______________________________________________ > Python-ideas mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/YO3AEGXU5YKBSGGVT4UXN4YTR54JNJVZ/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/6QL4KXKC7FFTJAT277D3RLT4MY46M3TB/ Code of Conduct: http://python.org/psf/codeofconduct/
