seeking deeper (language theory) reason behind Python design choice

[Python]

On Mon, May 14, 2018 at 12:02:47PM -0600, Ian Kelly wrote:
> 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.

I went on to say that the second reviewer was required (i.e. this
should be considered a required part of good process).  If you decide
this is your process and it's required then it's required, regardless
of what you personally think.

> 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.

I'm well acquainted with that pheonomenon, though I daresay that if
you proofread your own product you will often find your mistakes.  You
just won't always.  But, I never said review it right after you wrote
it, and in fact I don't do that (well, I do reread it if it seems
something potentially concerning).  Rather I review it when I'm about
to check it in, which for anything non-trivial is generally days
later, after it's been tested (which implies the tests were written).
I find my own bugs very often (but not nearly as often as I'd like).

I am hardly perfect.  What I am is thorough.  I would argue that is
required to write quality software.  If your goal is not to write
quality software, then none of this matters.  And if it is your goal,
you shouldn't need to care about this, because you'll either get it
right through whatever process you have, or you'll avoid it entirely
if you don't think your process is adequate.  Your choice.  Or not, if
the language decides you can't be responsible enough to make that
choice for yourself.

> 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?

These all seem fine, but if you're missing extremely well-known
pitfalls, then... I'll prefer a different code reviewer. :)  Maybe you
should consider adding that to your list.

> 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.

I don't disagree with that, except that I don't consider this a subtle
bug, largely on account of its aforementioned status as well-known
pitfall.  But niether do I consider it damning, obviously.

> In C, if I miss a misplaced '=' then the code will do the wrong
> thing. 

Better yet, the compiler should warn you about it (which I believe it
does).  And you should be compiling with warnings. 

> In Python, I don't even have to worry about it, and I like it that
> way. 

If you're so concerned about making that mistake, YOU CAN CHOOSE TO
NOT USE THAT CONSTRUCT.  It doesn't need to be a decision forced on
you by the compiler.

As we've learned in this thread, there is a PEP for implementing this
feature which Guido apparently approves, so it can't be all that evil
after all, can it?

> 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:

Actually if you read all of what I wrote, you'll know that what I said
was assignment as an expression should be allowed, and if there were
to be a different operator to express that to avoid confusion, that
would be just fine with me.  But I don't think that need be a
condition.

> "'=' as an expression should be supported because it's convenient to
> me, and I don't believe I write bugs

Convenience is sort of Python's gig, isn't it?  "Make simple things
easy, make hard things possible."

> and if I do it doesn't matter because my time is important than that
> of the person who reviews my code."

Circumstantially, that may actually be true... or it may not.  Depends
on who you're working with, their roles and seniority, relative skill
and compensation, and probably  other factors.  Most groups have such
a heirarchy, even if it is largely implied rather than stated.
HOWEVER it hardly matters if the construct in question is accepted
practice.