[Python-ideas] A comprehension scope issue in PEP 572

Brendan Barnwell brenbarn at brenbarn.net
Thu May 10 14:23:00 EDT 2018

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

More information about the Python-ideas mailing list