User DeTeReR asked a question (http://stackoverflow.com/questions/32521140/generator-as-function-argument) on Stack Overflow about a special case of code that seemed to work in Python 3.4:

    f(1 for x in [1], *[2])

and

    f(*[2], 1 for x in [1])

I found out that when Python 2.6 introduced the "keyword arguments after *args", the checks in ast.c did not follow:

    for (i = 0; i < NCH(n); i++) {
        node *ch = CHILD(n, i);
        if (TYPE(ch) == argument) {
            if (NCH(ch) == 1)
                nargs++;
            else if (TYPE(CHILD(ch, 1)) == gen_for)
                ngens++;
            else
                nkeywords++;
        }
    }
    if (ngens > 1 || (ngens && (nargs || nkeywords))) {
        ast_error(n, "Generator expression must be parenthesized "
                  "if not sole argument");
        return NULL;
    }

the *args, **kwargs were not considered to be of type "argument" by the Grammar, and thus the error was not generated in this case.

Further down, the error "non-keyword arg after keyword arg" was not triggered in the case of sole unparenthesized generator expression.

Now, the parsing changes in 3.5 have disallowed all of these constructs:

    f(1 for i in [42], **kw)
    f(1 for i in [42], *args)
    f(*args, 1 for i in [42])

which were (erroneously) allowed in previous versions.

I believe at least 3.5 release notes should mention this change.

I guess that it's a consequence of the PEP 448 "additional unpacking generalizations".

@haypo yes.

I must add that I found out that Python 2.5 also allows 

    f(1 for x in [1], *a)

and 

    f(1 for x in [1], **kw)

but not

    f(*a, 1 for x in [1])

So I do not know if the first and second cases were intentional or not.
Also, in Python 2.6 - 3.4, f(*a, 1 for x in [1]) provides the generator as the *first* positional argument, in 3.5 it'd be the last one.

According to the human readable grammar in the docs

   https://docs.python.org/3/reference/expressions.html#calls

I'd say this was a bug that is now fixed in 3.5. The call should
either take a single unparenthesized generator expression or an
argument_list (which may contain parenthesized generator expressions).

Yeah, it is a bug in 2.5 too; https://docs.python.org/2.5/ref/calls.html

    call ::= primary "(" [argument_list [","]
		         | expression genexpr_for] ")"

If we have decided that this is a "fixed bug", it should indeed be mentioned in what's new for 3.5 since it is a behavior change.

> If we have decided that this is a "fixed bug", [..]

I'd call this a bug fix.  The old syntax was completely unreadable.  

Should I close this issue?

> [..] it should indeed be mentioned in what's new for 3.5 since it is a behavior change.

Sure, I'll document it.

I think the issue can be closed (after updating "what's new").

Even if we wanted to keep backwards compatibility, it's too
late now.

New changeset 10a9d4acd9cb by Yury Selivanov in branch '3.5':
whatsnew/3.5 More edits
https://hg.python.org/cpython/rev/10a9d4acd9cb

What's new is now updated with description of this issue.  Closing it now.