Let examples speak:

    def x(a, z): pass      # this is ok
    def x(a, z,): pass     # this is ok
    def x(a, *, z): pass   # this is ok in Py3k
    def x(a, *, z,): pass  # but this causes SyntaxError (!)

    def x(a, *args): pass      # this is ok
    def x(a, *args,): pass     # but this causes SyntaxError
    def x(a, **kwargs): pass   # this is ok
    def x(a, **kwargs,): pass  # but this causes SyntaxError
    def x(a, *args, z): pass   # this is ok in Py3k
    def x(a, *args, z,): pass  # but this causes SyntaxError (!)

And similarly -- calls:

    def x(*args, **kwargs): pass
    x(1, *(2,3,4))        # this is ok
    x(1, *(2,3,4),)       # but this causes SyntaxError
    x(1, **{5: 6})        # this is ok
    x(1, **{5: 6},)       # but this causes SyntaxError
    x(1, 2, 3, 4, z=5)    # this is ok
    x(1, *(2,3,4), z=5)   # this is ok in Py2.6+ and Py3k
    x(1, *(2,3,4), z=5,)  # but this causes SyntaxError (!)

Similar problem was discussed years ago as a docs bug -- see: bpo-798652, but -- as inconsistent with intuition and a general Python rule that trailing commas are ok in argument lists and sequence literals (except empty ones) -- it seems to be rather a language syntax definition issue.

Now, after introducing new syntax possibilities in Py2.6 and especially Py3k (see the examples above), the issue is even much more painful.

Also, please consider that Py3k's function annotations encourage to format argument list in one-argument-per-line-manner:

    def my_func(
        spam:"Very tasty and nutritious piece of food",
        ham:"For experts only",
        *more_spam:"Not less tasty and not less nutritious!",
        spammish:"Nobody expects this!"='Inquisition',
    ):
        ...

s/{5: 6}/{'5': 6}/g (but it's a detail)

Oops, I see the problem was partly addressed @ bpo-9232.

But:

• the proposed patch doesn't fix calls (but defs only),

• shouldn't be the issue considered as a bug -- and fixed also in 2.7 and 3.1?

It's clearly not a bug: the documented grammar matches the implemented grammar. Asking for more abstract consistency is a feature request. This also clearly falls under the PEP-3003 moratorium.

The current behavior for function definitions is beneficial because a trailing comma in the argument list is likely to signal a real error (omitted variable).

In contrast, the trailing comma for lists is useful because entries on separate lines in a repeating pattern that makes it easy to add or remove entries.

The use cases for both function definitions and lists are best served by the current behavior, more so that a notion driven by "foolish consistency".

Recommend rejecting and closing.

I'm with Raymond; this is unneeded consistency. I honestly would rather see what little support there is for a trailing comma to go away, but w/o looking at the grammar I am willing to bet that would be a pain to get right and not be worth the effort.

Ok, so closing as rejected.

unneeded consistency

"unneeded" consistency !:?

I'd say that either there is a "full or complete" consistency on the mentionned point/element of syntax, or there is none .. but an unneeded one.. or an half-one, isn't "consistent consistency" by then ;)

This is an old issue, but where I run into it frequently is when I use the format function and string interpolation. For example, this throws a SyntaxError:

"The name of the person is {name_first} {name_last}".format(
**my_obj.__dict__,
)

Because strings tend to be fairly long, it's pretty common that the arguments to format end up on their own line.

I was always taught to use trailing commas in Python, and I'm fanatical about ensuring they're there. It's a smart part of the language that saves you from many bugs and much typing when copy/pasting/tweaking.

This is the first time I've ever run into an implementation bug in CPython, and at least from the post on StackOverflow, this looks like the parser isn't obeying the grammar: https://stackoverflow.com/questions/16950394/python-why-is-this-invalid-syntax