[Python-Dev] PEP 572: A backward step in readability

[Raymond Hettinger]

> On Apr 30, 2018, at 9:37 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> 
> On Mon, Apr 30, 2018 at 08:09:35AM +0100, Paddy McCarthy wrote:
> [...]
>> A PEP that can detract from readability; *readability*, a central
>> tenet of Python, should
>> be rejected, (on principle!), when such objections are treated so dismissively.
> 
> Unless you have an objective measurement of readability, that objection 
> is mere subjective personal preference, and not one that everyone agrees 
> with.

Sorry Steven, but that doesn't seem like it is being fair to Paddy.
Of course, readability can't be measured objectively with ruler
(that is a false standard).  However, readability is still a real issue
that affects us daily even though objective measurement aren't possible.

All of us who do code reviews make assessments of readability
on a daily basis even though we have no objective measures.
We know hard to read when we see it.

In this thread, several prominent and highly experienced devs
reported finding it difficult to parse some of the examples and
some mis-parsed the semantics of the examples.  It is an objective
fact that they reported readability issues.  That is of great concern
and shouldn't be blown off with a comment that readability,
"is a mere subjective personal preference".  At its heart, readability
is the number one concern in language design.

Also, there another area where it looks like valid concerns
are being dismissed out of hand.  Several respondents worried
that the proposed feature will lead to writing bad code.  
Their comments seem to have been swept under the table with
responses along the lines of "well any feature can be used badly,
so we don't care about that, some people will write bad code no
matter what we do".  While that is true to some extent, there remains 
a valid issue concerning the propensity for misuse.

ISTM the proposed feature relies on users showing a good deal
of self-restriaint and having a clear knowledge of boundary
between the "clear-win" cases (like the regex match object example)
and the puzzling cases (assignments being used in and-operator
and or-operator chains).  It also relies on people not making
hard to find mistakes (like mistyping := when == was intended).

There is a real difference between a feature that could be abused
versus a feature that has a propensity for being misused, being
mistyped, or being misread (all of which have occurred multiple
times in these threads).


> The "not readable" objection has been made, extremely vehemently, 
> against nearly all major syntax changes to Python:

I think that is a false recollection of history.  Comprehensions were
welcomed and highly desired.  Decorators were also highly sought
after -- there was only a question of the best possible syntax. 
The ternary operator was clamored for by an enormous number
of users (though there was little agreement on the best spelling).
Likewise, the case for augmented assignments was somewhat strong
(eliminating having to spell the assignment target twice).

Each of those proposals had their debates, but none of them 
had a bunch of core devs flat-out opposed like we do now.
It really isn't the same at all.

However, even if the history had been recalled correctly, it would
still be a logical fallacy to posit "in the past, people opposed
syntax changes that later proved to be popular, therefore we
should ignore all concerns being expressed today".  To me,
that seems like a rhetorical trick for dismissing a bunch of
thoughtful posts.

Adding this new syntax is a one-way trip -- we don't get to express
regrets later.   Accordingly, it would be nice if the various concerns
being presented were addressed directly rather than being
dismissed with a turn of phrase.  Nor should it matter whether
concerns were articulately expressed (being articulate isn't
always correlated with being right).


Raymond