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 <> wrote:
On Sat, Apr 11, 2020 at 7:06 AM Elliott Dehnbostel
<> 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

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.

Python-ideas mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct: