seeking deeper (language theory) reason behind Python design choice

[Python]

On Tue, May 08, 2018 at 11:36:06PM -0600, Ian Kelly wrote:
> On Tue, May 8, 2018 at 9:48 PM, Python <python at bladeshadow.org> wrote:
> > I'll give you an example that is both a case where Python's design
> > choices make creating a bug easier, AND a case where allowing
> > assignments to be expressions would save you.
> >
> >     flag = we_are_done()
> >     while not flag:
> >         # do some stuff
> >         ...
> >         if error_occured():
> >             break
> >         falg = we_are_done()
> >     notify_user()
> >    # flag will be checked again later, perhaps for error reporting
> 
> while True:
>     if we_are_done():
>         break
>     # do some stuff
>     ...
>     if error_occurred():
>         break
> notify_user()
> 
> Fixed, using idiomatic Python and without needing to use assignment in
> an expression.

Two points:

1. I think the ensuing discussion clearly enough demonstrates that
   this isn't necessarily considered the most idiomatic Python.  I
   would go so far as to say it demonstrates that there's no such
   thing in actuality, in that different "experts" will have different
   opinions about what is or is not Pythonic.

2. Even if there was a definitive standard as to what is or is not
   idiomatic Python, no one is required to write it or care about it,
   and I would estimate that the vast majority of people who write
   Python don't.  People tend to use constructions they're familiar
   with and/or comfortable with, until they discover for themselves a
   reason not to.

On Thu, May 10, 2018 at 08:38:39PM -0600, Ian Kelly wrote:
> In what way does "while True" in the general case pretend to be an
> infinite loop? The break / return is right there for anyone to see.

It doesn't pretend at all, it simply is.  Its loop condition is a
constant which will require the loop to continue indefinitely--in the
general case--without intervention from some other control feature, in
the specific.