On 17.10.2016 22:12, Paul Moore wrote:
- Whether you choose to believe me or not, I've sincerely tried to
understand the proposal [...]
I think you did and I would like others to follow your example.
- Can someone summarise the *other* arguments for the proposal?
I for one think it's just restriction lifting. If that doesn't suffice, that's okay.
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.
Sorry? You know, I am all for real-world code and I also delivered: https://mail.python.org/pipermail/python-ideas/2016-October/043030.html
If it doesn't meet your standards of real-world code, okay. I meets mine.
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.
I do. Every usage of chain.from_iterable is that, well, "workaround". Workaround is too hard I think. It's more of an inconvenience.
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).
That's fair. As we see it, trainers deliberately choose to omit some language features they personally feel uncomfortable with. So, yes, if there were trainers who routinely reported this, that would be a strong argument for it. However, the absence of this signal, is not an argument against it IMHO.
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.
Same here. The discussion is inconclusive. I think it's best to drop it for the time being.