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

[Sven R. Kunze]

On 12.10.2016 17:41, Nick Coghlan wrote:
> This particular proposal fails on the first question (as too many
> people would expect it to mean the same thing as either "[*expr, for
> expr in iterable]" or "[*(expr for expr in iterable)]")

So, my reasoning would tell me: where have I seen * so far? *args and 
**kwargs! [...] is just the list constructor. So, putting those two 
pieces together is quite simple. I expect that Martti's reasoning was 
similar.

Furthermore, your two "interpretations" would yield the very same result 
as [expr for expr in iterable] which doesn't match with my experience 
with Python so far; especially when it comes to special characters. They 
must mean something. So, a simple "no-op" would not match my expectations.

> but it fails on the other two grounds as well.

Here I disagree with you. We use *args all the time, so we know what * 
does. I don't understand why this should not work in between brackets [...].

Well, it works in between [...] sometimes but not always, to be precise. 
And that's the problem, I guess.

> In most uses of *-unpacking it's adding entries to a comma-delimited
> sequence, or consuming entries in a comma delimited sequence (the
> commas are optional in some cases, but they're still part of the
> relevant contexts). The expansions removed the special casing of
> functions, and made these capabilities generally available to all
> sequence definition operations.

I don't know what you mean by comma-delimited sequence. There are no 
commas. It's just a list of entries. * adds entries to this list. (At 
least from my point of view.)

> Comprehensions ... [are] inspired by mathematical set builder notation.

Exactly. Inspired. I don't see any reason not to extend on this idea to 
make it more useful.

> "itertools.chain.from_iterable(subiter for subiter in iterable)".

I have to admit that need to read that twice to get what it does. But 
that might just be me.

Cheers,
Sven