On 2018-05-10 11:05, Tim Peters wrote:
So long as I'm the only one looking at real-life use cases, mine is
the only evidence I care about ;-) I don't really care about
contrived examples, unless they illustrate that a proposal is
ill-defined, impossible to implement as intended, or likely to have
malignant unintended consequences out-weighing their benefits.
You keep saying things like this with a smiley, and I realize you know
what you're talking about (much more than I do), but I'd just like to
push back a bit against that entire concept.
Number one, I think many people have been bringing in real life uses
cases. Number two, I disagree with the idea that looking at individual
use cases and ignoring logical argumentation is the way to go. The
problem with it is that a lot of the thorny issues arise in
unanticipated interactions between constructs that were designed to
handle separate use cases.
I also do not think it's appropriate to say "if it turns out there's a
weird interaction between two features, then just don't use those two
things together". One of the great things about Python's design is that
it doesn't just make it easy for us to write good code, but in many ways
makes it difficult for us to write bad code. It is absolutely a good
idea to think of the broad range of wacky things that COULD be done with
a feature, not just the small range of things in the focal area of its
intended use. We may indeed decide that some of the wacky cases are so
unlikely that we're willing to accept them, but we can only decide that
after we consider them. You seem to be suggesting that we shouldn't
even bother thinking about such corner cases at all, which I think is a
dangerous mistake.
Taking the approach of "this individual use case justifies this
individual feature", leads to things like JavaScript, a hellhole of
special cases, unintended consequences, and incoherence between
different corners of the language. There are real cognitive benefits to
having language features make logical and conceptual sense IN ADDITION
TO having practical utility, and fit together into a unified whole.
Personally my feeling on this whole thread is that these changes, if
implemented are likely to decrease the average readability of Python
code, and I don't see the benefits as being worth the added complexity.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
