PEP 572: A backward step in readability
The PEP s section on Frequently raised objections includes: (https://www.python.org/dev/peps/pep-0572/#this-could-be-used-to-create-ugly-...)
This could be used to create ugly code!
So can anything else. This is a tool, and it is up to the programmer to use it where it makes sense, and not use it where superior constructs can be used.
The above is so dismissive of a very real problem. * Python makes syntax decisions to make it easier to read. * One of the first, and enduring ones was "No assignment within expressions". * I had both seen, and debugged problems in the C-language caused by assignment expressions; and was glad to be rid of them in Python. Assignment within expressions was, I think, difficult to *teach* in C. And will become something error-prone to *learn* in Python. The Python community has grown over the decades, and we have attracted community members who want to help and are motivated, but Python is not a tick-list of features. 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.
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. I for one think that used wisely, binding expressions will be *more* readable than the alternatives. (Even though := is not my preferred syntax.) The "not readable" objection has been made, extremely vehemently, against nearly all major syntax changes to Python: - comprehensions? not readable, easy to abuse, hard for beginners to comprehend; - decorators? not readable, looks like Perl with the arbitrary use of @ symbol, hard to understand; - ternary if operator? not readable, doesn't look enough like C, weird order; - augmented assignments += etc -- not readable, too terse, requires the reader to be familiar with C. I was guilty of making that last one. And if I had been around for the debate over decorators, I probably would have hated them too. But all four additions to the syntax have been *great* for the language, despite the nay-sayers. I still know people with many years experience in Python who say they don't get comprehensions, and of course it is true that they are hard for beginners to get. But the advantages from comprehensions is immeasurably greater than the disadvantages. Will this PEP be like comprehensions or decorators, and completely change the way we write Python code (for the better)? I doubt it. But I expect it will be like augmented assignment and the ternary if: it will make certain kinds of code more pleasurable to write *and read*, and when it doesn't, people won't use it. -- Steve
On 30 April 2018 at 17:37, Steven D'Aprano <steve@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. I for one think that used wisely, binding expressions will be *more* readable than the alternatives. (Even though := is not my preferred syntax.)
On the other hand, the PEP doesn't do much to address the various claims of readability issues. Whether they are subjective or not, well-founded or not, the PEP does (in my view) come across as unnecessarily dismissive of the question of readability. I suspect that's largely due to Chris being extremely tired of having the same arguments over and over again, and I can understand that. However, I think it could be covered more completely - the remainder of your post is exactly the sort of response that would be useful to have recorded. But one way or another, I think people will vote on the PEP based on their (subjective) views, and so readability will get factored into the overall response, one way or another. To what extent that response affects Guido's final decision (I can't see him delegating on this one!) remains to be seen, and honestly, I'm willing to trust Guido's intuition. Paul
TBH I think the text of the PEP could be much improved -- for example it should use motivating examples from real code, not artificial examples to show edge cases of the semantics. At this point I don't think that more people expressing an opinion one way or another are going to make a difference. Nobody whose vote matters is going to be convinced either way. On Mon, Apr 30, 2018 at 9:53 AM, Paul Moore <p.f.moore@gmail.com> wrote:
On 30 April 2018 at 17:37, Steven D'Aprano <steve@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. I for one think that used wisely, binding expressions will be *more* readable than the alternatives. (Even though := is not my preferred syntax.)
On the other hand, the PEP doesn't do much to address the various claims of readability issues. Whether they are subjective or not, well-founded or not, the PEP does (in my view) come across as unnecessarily dismissive of the question of readability. I suspect that's largely due to Chris being extremely tired of having the same arguments over and over again, and I can understand that. However, I think it could be covered more completely - the remainder of your post is exactly the sort of response that would be useful to have recorded.
But one way or another, I think people will vote on the PEP based on their (subjective) views, and so readability will get factored into the overall response, one way or another. To what extent that response affects Guido's final decision (I can't see him delegating on this one!) remains to be seen, and honestly, I'm willing to trust Guido's intuition.
Paul _______________________________________________ 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/ guido%40python.org
-- --Guido van Rossum (python.org/~guido)
On 04/30/2018 12:37 PM, Steven D'Aprano wrote:
- comprehensions? not readable, easy to abuse, hard for beginners to comprehend;
I still refer to them as "list incomprehensions" in my head, particularly for those whic expand across line breaks. Tres. -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com
On 30 April 2018 at 17:37, Steven D'Aprano <steve@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.
True, as is the dismissal from the PEP. It is the PEP, looking to force change to the language, to prove its point rather than dismiss statements of its detractors.
The "not readable" objection has been made, extremely vehemently, against nearly all major syntax changes to Python:
I don't count myself as usually against change. I applaud the move to Python 3, I use all of the language features you mention at times; many in my Rosetta Code task examples; but this change opens the door to a class of bug that will take care to avoid and which I remember cutting my C coding to get away from. The PEP fails to adequately address the concerns of "us naysayers" For example; if someone were to find out that "assignment expressions were faster", then you would be hard pressed to stop their over-use. As soon as someone assigns to a name and uses that same name in the one expression, you need a better grasp of the order of expression evaluation to read it. hat is best avoided, in my subjective, personal, view.
-- Steve
With respect, but in disagreement - Paddy.
On Apr 30, 2018, at 9:37 AM, Steven D'Aprano <steve@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
participants (6)
-
Guido van Rossum -
Paddy McCarthy -
Paul Moore -
Raymond Hettinger -
Steven D'Aprano -
Tres Seaver