seeking deeper (language theory) reason behind Python design choice
Steven D'Aprano
steve+comp.lang.python at pearwood.info
Mon May 14 20:52:42 EDT 2018
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
More information about the Python-list
mailing list