> On Apr 30, 2018, at 9:37 AM, Steven D'Aprano <st...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
