On 17.10.2016 22:12, Paul Moore wrote:
4. 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.
I for one think it's just restriction lifting. If that doesn't suffice,
2. Can someone summarise the *other* arguments for the proposal?
Sorry? You know, I am all for real-world code and I also delivered:
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.
If it doesn't meet your standards of real-world code, okay. I meets mine.
I do. Every usage of chain.from_iterable is that, well, "workaround".
Workaround is too hard I think. It's more of an inconvenience.
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
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.
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).
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.
Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/