On 17 October 2016 at 18:32, Steven D'Aprano <st...@pearwood.info> wrote: > On Mon, Oct 17, 2016 at 12:11:46PM -0400, Random832 wrote: > >> Honestly, it goes beyond just being "wrong". The repeated refusal to >> even acknowledge any equivalence between [...x... for x in [a, b, c]] >> and [...a..., ...b..., ...c...] truly makes it difficult for me to >> accept some people's _sincerity_. > > While we're talking about people being insincere, how about if you take > a look at your own comments? This "repeated refusal" that you accuse us > (opponents of this proposal) of is more of a rhetorical fiction than an > actual reality. Paul, David and I have all acknowledged the point you > are trying to make. I won't speak for Paul or David, but speaking for > myself, it isn't that I don't understand the point you're trying to > make, but that I do not understand why you think that point is > meaningful or desirable.
For my part: 1. I've acknowledged that equivalence. As well as the fact that the proposal (specifically, as explained formally by Greg) is understandable and a viable possible extension. 2. I don't find the "interpolation" equivalence a *good* way of interpreting list comprehensions, any more than I think that loops should be explained by demonstrating how to unroll them. 3. I've even explicitly revised my position on the proposal from -1 to -0 (although I'm tending back towards -1, if I'm honest...). 4. Whether you choose to believe me or not, I've sincerely tried to understand the proposal, but I pretty much had to insist on a formal definition of syntax and semantics before I got an explanation that I could follow. However: 1. I'm tired of hearing that the syntax is "obvious". This whole thread proves otherwise, and I've yet to hear anyone from the "obvious" side of the debate acknowledge that. 2. Can someone summarise the *other* arguments for the proposal? I'm genuinely struggling to recall what they are (assuming they exist). It feels like I'm hearing nothing more than "it's obvious what this does, it's obvious that it's needed and the people saying it isn't are wrong". That may well not be the truth, but *it's the impression I'm getting*. I've tried to take a step back and summarise my side of the debate a couple of times now. I don't recall seeing anyone doing the same from the other side (Greg's summarised the proposal, but I don't recall anyone doing the same with the justification for it). 3. The fact is that the proposed behaviour was *specifically* blocked, *precisely* because of strong concerns that it would cause readability issues and only had "mild" support. I'm not hearing any reason to change that decision (sure, there are a few people here offering something stronger than "mild" support, but it's only a few voices, and they are not addressing the readability concerns at all). There was no suggestion in the PEP that this decision was expected to be revisited later. Maybe there was an *intention* to do so, but the PEP didn't state it. I'd suggest that this fact alone implies that the people proposing this change need to write a new PEP for it, but honestly I don't think the way the current discussion has gone suggests that there's any chance of putting together a persuasive PEP, much less a consensus decision. And finally, no-one has even *tried* to explain why we need a third way of expressing this construction. Nick made this point, and basically got told that his condition was too extreme. He essentially got accused of constructing an impossible test. And yet it's an entirely fair test, and one that's applied regularly to proposals - and many *do* pass the test. It's worth noting here that we have had no real-world use cases, so the common approach of demonstrating real code, and showing how the proposal improves it, is not available. Also, there's no evidence that this is a common need, and so it's not clear to what extent any sort of special language support is warranted. We don't (as far as I know, and no-one's provided evidence otherwise) see people routinely writing workarounds for this construct. We don't hear of trainers saying that pupils routinely try to do this, and are surprised when it doesn't work (I'm specifically talking about students *deducing* this behaviour, not being asked if they think it's reasonable once explained). These are all arguments that have been used in the past to justify new syntax (and so reach Nick's "bar"). And we've had a special-case function (flatten) proposed to cover the most common cases (taking the approach of the 80-20 rule) - but the only response to that proposal has been "but it doesn't cover <artificial example>". If it didn't cover a demonstrably common real-world problem, that would be a different matter - but anyone can construct cases that aren't covered by *any* given proposal. That doesn't prove anything. I don't see any signs of progress here. And I'm pretty much at the point where I'm losing interest in having the same points repeated at me over and over, as if repetition and volume will persuade me. Sorry. Paul _______________________________________________ Python-ideas mailing list Pythonemail@example.com https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/