If we call some function f with a generator as star argument and this
generator raises a TypeError, we get the following exception:

>>> def f(x): pass
... 
>>> def broken(): raise TypeError
... 
>>> f(*(broken() for x in (0,)))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() argument after * must be a sequence, not generator

This is a misleading error message, as it's usually no problem to use a
generator as a star argument. Even just replacing the TypeError by some
other exception leads to the expected result, i.e. the exception gets
correctly propagated.

The problem seems to be around line 3710 of Python/ceval.c where the
generator is converted to a tuple. If this conversion raises a
TypeError, then the error message is replaced, which will mask any
TypeError raised by the generator.

I'm not sure how to solve this. We probably can't distinguish a "good"
TypeError from a "bad" TypeError at this point, so we might have to make
a special case for the conversion of generators.

The issue1615 has the same kind of problems: an AttributeError is masked
by another one.

I'm getting confused about whether it's actually desired behaviour that
generators can be star arguments.

The error message seems to say it's not: "argument after * must be a
sequence". The docs seem to agree: "If the syntax *expression appears in
the function call, expression must evaluate to a sequence." However
test_extcall specifically tests function calls with (non-sequence)
iterables as star arguments.

I can confirm that (a) this exact behavior is happening and (b) it quite
confused me (most of the time it works!). What would be a "good"
TypeError? I'd vote for generators to be explicitly supported even if it
required a special case. Thanks!

I added a simple check for iterables. This is not very elegant, but
performance is only affected in the case of an exception. Patch and
corresponsing test are attached as "TypeError.patch".

As I pointed out above, the actual error message "must be a sequence" is
also inconsistent with the implementation (and tests) which allows any
kind of iterable. The attached and independent patch
"message_and_docs.patch" changes this to "must be an iterable" and
corrects docs and tests accordingly.

This patch leaks a reference on each call to PyObject_GetIter(). And I'm
not sure it is a good idea to call this function again: it may be very
expensive! I'd prefer a simple check on the tp_iter member.

Sorry, I had meant to use PyIter_Check instead of PyObject_GetIter.
Don't know why I didn't do so... ;-)

I corrected the patch.

I have also hit this error.  I went to report it but found it already entered (good news), but not resolved from nearly a year ago (bad news).

The error masked another bug that I had in my program and it took me quite awhile to figure out what the real problem was.

I use *generator arguments quite a lot, so was surprised to see the error.  So I, for one, can say that if you disable *generator arguments, you will break existing code.

If anybody cares, I have verified that this error also appears in Python2.5 and Python2.4 and am attempting to add python2.5 to the Versions list.  (And yes, *generators were allowed in Python2.4!)

Is this headed for resolution?  Progress on it seems to have stalled nearly a year ago.  Can I vote to revive this?

I verified with 3.1 the two OP cases and that generators work fine as long as they supply the correct number of values.

def f(x): return x
def broken(): return 1
print(f(*(broken() for x in (0,))))
# prints 1

Change (0,) to (0,1) the normal arg num mismatch message appears.

test_extcall tests version of Nothing() that follow both the old and new iteration protocol. It is possible that 'sequence' in meant in the broader sense of finite iterable rather that the narrow sense of
5.6. Sequence Types — str, bytes, bytearray, list, tuple, range

Since that is confusing, I would replace 'sequence' with 'finite iterable'. (Infinite iterables, obviously, are bad, just as in any other uncontrolled situation, such as "a,*b = itertools.count()".)

So, combine the correction and the suggestion above with original and diff against current trunk (py3k branch) if you can or at least 3.1.2.

IIUC, the only change you suggest for my patch is using "finite iterable" instead of "sequence" or "iterable", right?

I've looked at the docs and there seems to be no precedent for "finite iterable". I think it's just as obvious that the iterable has to yield a correct (and finite) number of parameters as the fact that "list(itertools.count())" is a bad idea. So for consistency I would like to keep "iterable".

Ok, leave iterable as is. More important, you have two disjoint patches that I believe should be combined.

Attaching a combined patch against the current py3k.

I think the patch isn't entirely correct.  It uses PyIter_Check for detecting the case when an *iterable* raises TypeError, but that function actually checks for an *iterator*.  The check on the tp_iter member mentioned by Amaury Forgeot d'Arc probably would be better, but even that wouldn't detect every iterable: "Its presence normally signals that the instances of this type are iterable (although sequences may be iterable without this function)." (http://docs.python.org/dev/py3k/c-api/typeobj.html#PyTypeObject.tp_iter)  (Apparently any object with a __getitem__ is iterable.  By the way, collections.abc.Iterable also doesn't detect this case.)

I'm attaching an updated patch. Instead !PyIter_Check() this patch checks for tp_iter == NULL && !PySequence_Check.  If this condition is false, PyObject_GetIter has a chance to succeed (and if it fails, we shouldn't mask the exception).  I also added more tests which show why the previous patch was incorrect.

#11944 is probably a duplicate of this and should be checked when this is fixed

I haven’t tried to understand what the patches do, but Issue 5218 looks like a very similar problem with a patch including a test case.

#13904 is another dup, with patches to test and ceval. I asked that they be reloaded to this issue.

#5218 is a 4th duplicate, also with a patch to the ceval loop and test.

Sorry Martin, I see you already said that. Anyway, I closed other three in favor of this one.