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

[Stephen J. Turnbull]

אלעזר writes:

 > Steve, you only need to allow multiple arguments to append(), then it makes
 > perfect sense.

No, because that would be explicit.  Here it's implicit and ambiguous.
Specifically, it requires guessing "operator associativity".  That is
something people have different intuitions about.

 > > On Tue, Oct 11, 2016 at 02:42:54PM +0200, Martti Kühne wrote:
 > > > Hello list
 > > >
 > > > I love the "new" unpacking generalisations as of pep448. And I found
 > > > myself using them rather regularly, both with lists and dict.
 > > > Today I somehow expected that [*foo for foo in bar] was equivalent to
 > > > itertools.chain(*[foo for foo in bar]), which it turned out to be a
 > > > SyntaxError.

Which is what I myself would expect, same as *(1, 2) + 3 is a
SyntaxError.  I could see Nick's interpretation that *foo in such a
context would actually mean (*foo,) (i.e., it casts iterables to
tuples).  I would certainly want [i, j for i, j in [[1, 2], [3, 4]]]
to evaluate to [(1, 2), (3, 4)] (if it weren't a SyntaxError).

 > > To me, that's a very strange thing to expect. Why would you expect that
 > > unpacking items in a list comprehension would magically lead to extra
 > > items in the resulting list? I don't think that makes any sense.

Well, that's what it does in display syntax for sequences.  If you
think of a comprehension as a "macro" that expands to display syntax,
makes some sense.  But as you and Nick point out, comprehensions are
real operations, not macros which implicitly construct displays, then
evaluate them to get the actual sequence.

 > > Wishful thinking perhaps?

That was unnecessary.  I know sometimes I fall into the trap of
thinking there really ought to be concise syntax for a "simple" idea,
and then making one up rather than looking it up.