[Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

[Paul Moore]

On 17 October 2016 at 21:33, Sven R. Kunze <srkunze at mail.de> wrote:
> 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.
>>
>> 2. 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.

Paul