On Sat, Apr 11, 2020 at 7:06 AM Elliott Dehnbostel pydehnbostel@gmail.com 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 blockthen 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