[Python-Dev] Examples for PEP 572

[Brett Cannon]

On Tue, Jul 3, 2018, 22:27 Tim Peters, <tim.peters at gmail.com> wrote:

> [INADA Naoki]
> > ...
> > On the other hand, I understand PEP 572 allows clever code
> > simplifies tedious code.  It may increase readability of non-dirty
> code.
>
> The latter is the entire intent ,of course.  We can't force people to
> write readable code, but I don't understand the widespread assumption that
> other programmers are our enemies who have to be preemptively disarmed ;-)
>
> Use code review to enforce readable code.  If you want a coding standard
> here, use mine:  "if using an assignment expression isn't obviously better
> (at least a little so), DON'T USE IT".  That's the same standard I use for
> lots of things (e.g., is such-&-such better as a listcomp or as nested
> loops?).  It only requires that you have excellent taste in what "better"
> means ;-)
>

I think this is a very key point that the "this is bad" crowd is
overlooking. Even if this syntax turns out to not be that useful, abusing
the walrus operator can be fixed with a comment of "hard to follow; please
simplify" without teaching any new concepts or idioms (and which happens
with constructs most of us would agree are useful and well-designed). IOW
when I'm doing code reviews for folks this is not going to be what I stress
about or spill the most characters trying to explain how to fix.



> As I noted in the PEP's Appendix A, I refuse to even write code like
>
> i = j = count = nerrors = 0
>
> because it squashes conceptually distinct things into a single statement
> .  I'll always write that as
>
> i = j = 0
> count = 0
> nerrors = 0
>
> instead - or even in 4 lines if `i` and `j` aren't conceptually related.
>
> That's how annoyingly pedantic I can be ;-)   Yet after staring at lots of
> code, starting from a neutral position (why have an opinion about anything
> before examination?), I became a True Believer.
>
> I really don't know what Guido likes best about this, but for me it's the
> large number of objectively small wins in `if` and `while` contexts.   They
> add up.  That conclusion surprised me.  That there are occasionally bigger
> wins to be had is pure gravy.
>

Another point is we live in a dictatorship by choice, and yet some people
seem very upset our dictator dictated in the end. 😉 Rather than being
upset that Guido chose not to heed some advice that someone personally
thought was crucial, I'm going to rely on the point that all the salient
points were made (albeit sometimes in sensationalist terms in what seems
like a higher-than-normal frequency), and trust Guido's design taste which
I have appreciated for my 18 years as a Python user.

-Brett


> But in no case did I count "allows greater cleverness" as a win.  The
> Appendix contains a few examples of "bad" uses too, where cleverness in
> pursuit of brevity harms clarity.  In fact, to this day, I believe those
> examples derived from abusing assignment expressions in real-life code are
> more horrifying than any of the examples anyone else _contrived_ to "prove"
> how bad the feature is.
>
> I apparently have more faith that people will use the feature as
> intended.  Not all people, just most.  The ones who don't can be beaten
> into compliance, same as with any other abused feature ;-)
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180704/426b4ff4/attachment.html>