On Wed, Apr 25, 2018 at 01:55:37PM -0700, Łukasz Langa wrote:
On 25 Apr, 2018, at 1:28 PM, Guido van Rossum <guido@python.org> wrote:
You don't seem to grasp the usability improvements this will give. I hear you but at this point appeals to Python's "Zen" don't help you.
This reads dismissive to me. I did read the PEP and followed the discussion on python-dev. I referred to PEP 20 because it distills what's unique about the value proposition of Python. It's our shared vocabulary.
Every programming language has a shared vocabulary. That's hardly unique to Python.
Can you address the specific criticism I had? To paraphrase it without PEP 20 jargon:
(name := expression) makes code less uniform. It inserts more information into a place that is already heavily packed with information (logic tests).
I'm not Guido, but I'll make an attempt. I think the comment about "less uniform" isn't meaningful. Uniform in what way? I don't even know how to interpret the uniform comment here, unless you mean to imply that every statement and expression in Python currently has the same information density, and binding-expressions will violate that. That's clearly not the case, so I'm left puzzled by what you mean. As for your observation that binding-expressions don't reduce complexity, they merely move it, I think you may be right. But then it is a truism that complexity is never reduced, only moved, so that's likely to be true for any feature (including existing ones). Should we move back to assembly language programming because Python hasn't reduced complexity, only moved it? I don't think so. Clearly binding-expressions do add a little more complexity to the language, and they do move code from vertically separated statements to horizontally laid-out expressions. But why is this necessarily a bad thing? Exactly the same complaint can be made about comprehensions, and look at how wildly successful they have been. Offset against the increase in horizontal complexity is a corresponding decrease in vertical complexity, and that's beneficial. Whatever cost they have has to be offset against the benefits, and I think the feature will come ahead on the plus side overall. Of course, like any syntactic feature, it may be abused by those who (by accident or design) write obfuscated or excessively complex code. We shouldn't ignore that risk, but nor should we use that as an excuse to dismiss the feature's benefits. -- Steve