[issue2292] Missing *-unpacking generalizations

[Guido van Rossum]

Guido van Rossum added the comment:

So I think the test function here should be:

  def f(*a, **k): print(list(a), list(k))

Then we can try things like:

  f(x for x in ['ab', 'cd'])

which prints a generator object, because this is interpreted as an argument that's a generator expression.

But now let's consider:

  f(*x for x in ['ab', 'cd'])

I personally expected this to be equivalent to:

  f(*'ab', *'cd')

IOW:

  f('a', 'b', 'c', 'd')

However, it seems your current patch (#18) interprets it as still passing a single argument which is the generator expression (*x for x in ['ab', 'cd']) which in turn is equivalent to iter(['a', 'b', 'c', 'd']), IOW f() is called with a single argument that is a generator.

The PEP doesn't give clarity on what to do here.  The question now is, should we interpret things like *x for x in ... as an extended form of generator expression, or as an extended form of *arg?  I somehow think the latter is more useful and also the more logical extension.

My reasoning is that the PEP supports things like f(*a, *b) and it would be fairly logical to interpret f(*x for x in xs) as doing the *x thing for each x in the list xs.

I think this same interpretation works for [*x for x in xs] and {*x for x in xs}, and we can also extend it to ** in {} and in calls (obviously ** has no meaning in list comprehensions or generator expressions).

BTW I think I found another bug in patch #18:

  >>> {**1}
  1
  >>> 

That should be an error.

An edge case I'm not sure about: should {**x} accept an iterable of (key, value) pairs, like dict(x)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2292>
_______________________________________