seeking deeper (language theory) reason behind Python design choice

[Chris Angelico]

On Sun, May 13, 2018 at 12:42 PM, Python <python at bladeshadow.org> wrote:
> On Wed, May 09, 2018 at 12:46:07PM -0400, Dennis Lee Bieber wrote:
>> On Tue, 8 May 2018 22:48:52 -0500, Python <python at bladeshadow.org>
>> >    if spam == arg:
>>
>>       Mis-typing that as
>>
>>       if spam = arg:
>>
>> IS the problem -- you've just changed the value bound to spam, and will
>> then branch based upon the new value and not a comparison of values.
>
> Yes, I'm well aware.  While I may have been momentarily confused about
> the side effects question, if you read my post I was clearly not
> confused about this.  Nor do I think anyone else who pposted in the
> thread needed it explained.
>
> Responding to this further would essentially just require me to
> reiterate what I already wrote--I won't do that.  I'll simply maintain
> that in my rather lenghty experience, this mistake has actually been
> rather rare and has to my knowledge *never* caused a support issue
> requiring a bug fix to production code in projects I've been
> associated with.  It's a useful construction whose detriment has, IMO,
> been completely overblown.
>

That's fine. Your experience has been that it hasn't been a problem;
other people's experience has been the opposite. I have never
personally had to deal with bugs in C code where braces are omitted
and multiple lines indented. Great! But that doesn't mean it's not a
problem, or at least a risk.

Guido has firmly stated that this is not going to happen in Python.
The '=' operator is NOT going to become an expression. You may as well
stop posting about it, because it's not going to change.

ChrisA