seeking deeper (language theory) reason behind Python design choice

Python python at bladeshadow.org
Sat May 12 23:08:10 EDT 2018


Drat, missed the main point I wanted to address in my last post:

On Tue, May 08, 2018 at 11:36:06PM -0600, Ian Kelly wrote:
> > This example also is a case FOR allowing assignments to be
> > expressions.  If Python allowed them, you could rewrite this as:
> >
> >    while not (flag = we_are_done()):
> >         ...
> >         if error_occured():
> >             break
> >    notify_user()
> >    # flag will be checked again later, perhaps for error reporting
> >
> > This COMPLETELY PREVENTS the spelling bug in the code above, since the
> > assignment only happens in one place; and as a bonus it's less code.
> 
> Or just use an IDE with variable name autocompletion.

Every time, without fail?  Probably not going to happen, no matter who
you are.  FWIW I *do* use an editor with autocompletion--I never use
it because in the common case it's faster for me to just type whatever
I'm typing.  But this solution--dictating *how* people work, to
overcome a limitation of the language--is a horrible one.

Besides, your entire response missed the point completely..  All of
the examples you "fixed" were just trivial academic examples designed
to illustrate the problem.  In real code, particularly in a complex
project, the spelling bug is easier to cause and harder to find, and
just rewriting your while loop probably won't do.

My ultimate point was no matter what constructions you allow or don't
allow, coders are human and they're gonna screw it up, and some of
those mistakes will get past all of your well-intentioned bug traps.
Protecting coders from themselves is not a good reason to exclude
useful language constructs.  It's a reason to have good coders, good
process, and good testing.

And if your code reviews won't catch well-known programming pitfalls,
what good are they?




More information about the Python-list mailing list