seeking deeper (language theory) reason behind Python design choice

[Steven D'Aprano]

On Mon, 14 May 2018 18:20:13 -0500, Python wrote:

> I am hardly perfect.

Have you tried just wanting to be perfect more?


Look, we get it: it is possible to improve the quality of your code by 
paying attention to what you do, by proof-reading, testing, code reviews, 
warnings, linters, etc. We're not all doomed to be careless coders. I 
agree completely.

Also agree completely that assignment in expressions is sometimes useful.

Also agree that *with care and good management* it is possible to reduce 
the error rate from assignment-expressions to a manageable level -- even 
if assignment is spelled "=". Not to *zero*, but some non-zero manageable 
level.

But you miss the point that even if = versus == errors are picked up by 
code reviews or tests, they are still software bugs. Your *process* 
(testing and reviews) picked up the bug before they went into production, 
but *the bug still was made*.

A mere typo is not a bug if the compiler flags it before the code runs. 
It's just a typo.

So instead of congratulating yourself over how you never make the = 
versus == bug, you ought to be sheepishly realising how often you make 
it, but fortunately you have the processes in place to catch it before it 
reaches production.

Now remember that not every programmer works in large teams with pair 
programming, code reviews, test driven development, automatic buildbots 
to catch errors, etc.

Now remember that in 1991 when Guido made the decision to ban = as an 
expression, those concepts didn't even exist. There were no Python 
linters, and no reason to imagine that there ever would be. Guido didn't 
know that Python would become one of the top 10 most used languages. For 
all he knew, version 1.0 could be the final release.

By 1991 there had already been *decades* of experience with C proving 
that the "=" assignment syntax is dangerously confusable with == and a 
total bug magnet when allowed as expressions as well, so it was perfectly 
reasonable to ban it from the language.

There's nothing you can do with assignment expressions that can't be done 
*almost* as easily with assignment statements. Its often a matter of mere 
personal preference, do I want to write this as a single line or two?

And as the discussions over PEP 572 prove, the choice about allowing 
assignment expressions is *not easy*. Not only is there the matter of 
whether or not to allow it, but what spelling to use, and what scope the 
assignment should operate in.

And if you think that last one is the most trivial, in fact with list 
comprehensions and generator expressions, it will probably end up being 
the most controversial of all the questions.

And the most likely to sink the proposal.



-- 
Steve