On 17 October 2016 at 21:33, Sven R. Kunze firstname.lastname@example.org wrote:
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.
Thank you. You're correct that was mentioned. I infer from the responses that it isn't sufficient, but I should have noted it explicitly.
Elazar also mentioned consistency, which I had also forgotten. He noted in his comment (and I agree) that consistency isn't a compelling argument in itself. I'd generalise that point and say that theoretical arguments are typically considered secondary to real-world requirements.
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.
Apologies. I had completely missed that example. Personally, I'd be inclined to argue that you shouldn't try so hard to build the list you want to return in a single statement. You can build the return value using a loop. Or maybe even write a function designed to filter Postgres result sets, which might even be reusable in other parts of your program. It's not my place to tell you how to redesign your code, or to insist that you have to use a particular style, but if I were writing that code, I wouldn't look for an unpacking syntax.
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.
If this proposal had been described as "a syntax to replace chain.from_iterable", then it might have been received differently. I doubt it would have succeeded even so, but people would have understood the use case better. For my part, I find the name chain.from_iterable to be non-obvious. But if I needed to use it a lot (I don't!) I'd be more likely to simply come up with a better name, and rename it. Naming is *hard*, but it's worthwhile. One problem (IMO) of the "propose some syntax" approach is that it avoids the issue of thinking up a good name, by throwing symbols at the problem. (And you can't google for a string of symbols...)
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.
No-one is looking for arguments *against* the proposal. Like it or not "status quo wins" is the reality. People need to look for arguments in favour of the proposal.
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.
Thanks for the reasoned response.