On Apr 26, 2018, at 12:40 AM, Tim Peters email@example.com wrote:
[Raymond Hettinger firstname.lastname@example.org]
After re-reading all the proposed code samples, I believe that adopting the PEP will make the language harder to teach to people who are not already software engineers.
Can you elaborate on that?
Just distinguishing between =, :=, and == will be a forever recurring discussion, far more of a source of confusion than the occasional question of why Python doesn't have embedded assignment.
Also, it is of concern that a number of prominent core dev respondents to this thread have reported difficulty scanning the posted code samples.
I've used dozens of languages over the decades, most of which did have some form of embedded assignment.
Python is special, in part, because it is not one of those languages. It has virtues that make it suitable even for elementary school children. We can show well-written Python code to non-computer folks and walk them through what it does without their brains melting (something I can't do with many of the other languages I've used). There is a virtue in encouraging simple statements that read like English sentences organized into English-like paragraphs, presenting itself like "executable pseudocode".
Perl does it or C++ does it is unpersuasive. Its omission from Python was always something that I thought Guido had left-out on purpose, intentionally stepping away from constructs that would be of help in an obfuscated Python contest.
Yes, I'm a software engineer, but I've always pitched in on "help forums" too.
That's not really the same. I've taught Python to many thousands of professionals, almost every week for over six years. That's given me a keen sense of what is hard to teach. It's okay to not agree with my assessment, but I would like for fruits of my experience to not be dismissed in a single wisp of a sentence. Any one feature in isolation is usually easy to explain, but showing how to combine them into readable, expressive code is another matter. And as Yuri aptly noted, we spend more time reading code than writing code. If some fraction of our users finds the code harder to scan because the new syntax, then it would be a net loss for the language.
I hesitated to join this thread because you and Guido seemed to be pushing back so hard against anyone's who design instincts didn't favor the new syntax. It would be nice to find some common ground and perhaps stipulate that the grammar would grow in complexity, that a new operator would add to the current zoo of operators, that the visual texture of the language would change (and in a way that some including me do not find pleasing), and that while simplest cases may afford a small net win, it is a certitude that the syntax will routinely be pushed beyond our comfort zone.
While the regex conditional example looks like a win, it is very modest win and IMHO not worth the overall net increase language complexity.
Like Yuri, I'll drop-out now. Hopefully, you all wind find some value in what I had to contribute to the conversation.