seeking deeper (language theory) reason behind Python design choice

[Ian Kelly]

On Mon, May 14, 2018 at 9:38 AM, Python <python at bladeshadow.org> wrote:
> Absolutely correct.  If you're not doing THOROUGH code reviews, and
> not thoroughly testing your code, your job is only half done.  You
> should be your own first reviewer, and then have a second someone
> competent review it after you do.

One should never be their own "first reviewer" because it may lead to
the mindset that a "second reviewer" is unnecessary. You're about as
likely to notice the glaring bugs in the code that you just wrote as
you are to notice the missing or misspelled words in the sentence you
just penned. Why? Because you just wrote it, and as a result you
believe that you know what it says, and you'll simply fail to process
the fact that it actually says something different.

That said, when I'm doing a code review, my focus is on all of the
following things:

* Design: does this code make sense for what it's trying to accomplish?
* Functionality: does the code work as intended?
* Readability: can I understand it, and will others understand it later?
* Complexity: could this code be simpler?
* Tests: does the code include good tests?

The existence of subtle bugs are just one of the things that I'm
thinking about, so from my perspective, the more the compiler can help
with this, the better. In C, if I miss a misplaced '=' then the code
will do the wrong thing. In Python, I don't even have to worry about
it, and I like it that way. So when you say that '=' as an expression
should be supported because you think it's useful, and anyway those
sorts of bugs will be caught by code reviews, the way that reads to me
is:

"'=' as an expression should be supported because it's convenient to
me, and I don't believe I write bugs, and if I do it doesn't matter
because my time is important than that of the person who reviews my
code."