Python's current grammar allows a trailing comma after the argument list in:def f(a, b,):    passbut not indef f(*, a, b,):    passI propose allowing trailing commas in both situations.See python-dev discussion starting athttp://mail.python.org/pipermail/python-dev/2010-July/101636.html

Here's a patch.  I've checked withPEP 306, but besides changing Grammar, test_grammar.py and the parser module (which there's a separate issue open for), I don't think any other changes are required.

I take it the AST generation just throws the extra comma away? You're sure this doesn't upset any of the node counts in that stage of the compiler?

No, I'm not sure. :)  I'll double check.So I'm looking at ast_for_arguments and handle_keywordonly_args in ast.c.  As far as I can tell, that's the only relevant bit; is there anywhere else I should be checking?

There was one place that needed to be changed in ast.c:  namely, the check to make sure that there are keyword-only arguments following a bare star.Here's a new patch, that fixes that issue, updates the grammar in the ast.c comment to match that inGrammar/Grammar, and also updates the production list given in the docs for function definitions.

Retargetting, as this falls under the moratorium, and also because 3.2b1 has been released.

In#10682, several committers indicated that they would prefer not to change this. So I'm closing this as rejected. Per convention, it would probably require a PEP to modify Python in this aspect (as there is no clear consensus).

> In#10682, several committers indicated that they would prefer> not to change this.Issue#10682 has been open for less than 24 hours before it was rejected. In contrast, this issue was open after an almost week-long discussion on python-dev where the proposal was well received.I think#10682 should have been closed as a duplicate of this issue and this issue should be marked as "after moratorium".

I stand by my evaluation: there is clearly no consensus about this change, so it certainly requires more discussion, potentially leading to proponents being asked to write a PEP.

An open issue more accurately reflects the lack of consensus than a closed one, though. We just won't commit it until there *is* consensus that it is a better option than the status quo.

From 10682: the grammar is also inconsistent as to when trailing commas are allowed in function calls, not just definitions.

From 10682: The patch proposed in this (#9232) issue does not fix call syntax but def sytax only. I think it should fix call sytax as well (see code examples in#10682).

python-dev discussion continuation:http://mail.python.org/pipermail/python-dev/2010-December/106770.html

Moratorium's long over.  Will this patch rise from the dead?

> Will this patch rise from the dead?It's really down to getting consensus that it's a good idea.  That might require another python-dev discussion.

See alsoIssue 22942 about existing problems with the language documentation.I would like to see trailing commas supported consistently, especially in function calls. (I think the patch here only does function definitions?) I like to use them when writing arguments on multiple lines, and it is surprising that adding packed *positional arguments can trigger a syntax error.Maybe this is stretching the scope a bit too far, but it would also be nice to allow more keyword arguments after the **keyword unpacking:print(1, 2, end=".\n", *(3, 4))  # Supported, but confusingprint(1, 2, *(3, 4), end=".\n")  # Better; also suportedprint(1, 2, **dict(sep="-"), end=".\n")  # Unsupported, but would be niceprint(end=".\n", 1, 2)  # Unsupported, for good reasonMaybe some of this is covered byIssue 2292 (generalizing * unpacking), but I haven’t been following that, so I’m not sure.

It looks like if it was not for Raymond's mild dissent, [1], we wouldhave a consensus last time this was raised on python-dev, [2-7].[1] -? Raymond Hettingerhttps://mail.python.org/pipermail/python-dev/2010-December/106782.html[2] +0 Guido van Rossumhttps://mail.python.org/pipermail/python-dev/2010-December/106780.html[3] +0.5 Alexander Belopolskyhttps://mail.python.org/pipermail/python-dev/2010-December/106782.html[4] +1 Antoine Pitrouhttps://mail.python.org/pipermail/python-dev/2010-December/106783.html[5] +1 Glenn Lindermanhttps://mail.python.org/pipermail/python-dev/2010-December/106784.html[6] +1 Cameron Simpsonhttps://mail.python.org/pipermail/python-dev/2010-December/106788.html[7] +1 Terry Reedyhttps://mail.python.org/pipermail/python-dev/2010-December/106789.html

.. and a couple more -1's on the tracker:msg123851 - Martin v. Löwismsg123848 - Brett CannonIt looks like a round on python-ideas is needed before this can move forward.

Actual post by Raymond: <https://mail.python.org/pipermail/python-dev/2010-December/106790.html>Just noticed there are some arguments for trailing commas in the FAQ: <https://docs.python.org/dev/faq/design.html#why-does-python-allow-commas-at-the-end-of-lists-and-tuples>

Have also been confronted to this bug (imo) and this happen from time to time to me : I often like to ends my (big) functions defs and calls (those that span over multiple lines thus..) with that extra comma, so that when/if I add another argument (on a new line) later then there will be only a + line in my VCS).There seems to have a consensus to apply the patch (unless it's not finished?)..regards,

Reposting from from my newest duplicate of this issue (Issue 24677), which is now closed:I think that a trailing comma in function definition should be allowed also after *. Current situation with definitions:def f(*args, ): pass # SyntaxErrordef f(*, ): pass # SyntaxErrordef f(*, a, ): pass # SyntaxErrordef f(*, a=2, ): pass # SyntaxErrordef f(a, ): pass # Okdef f(, ): pass # SyntaxError – this should probably stay errorCorresponding calls:f(*args, ) # Okf(*args, a, ) # Okf(*args, a=2, ) # Ok f(a, ) # Okf(, ) # SyntaxError – this is why the corresponding def behavior should stayMy use case:def f(*,         long = 1,         list = 2,         of = 3,         kwonly = 4,         parameters = 5,     ):    ...

FWIW I would like to see this, but I think it does need a PEP given the contention so far. For that, we need a BDFL delegate AIUI.

Some remarks:• A trailing comma after a non-empty argument list is allowed in every call form, including class statement and optional call in decorator syntax. In the grammar, this correponds to `arglist`.• In function definition, trailing comma is allowed only if there is no star before:def f(a, b, c,): # alloweddef f(a=1, b=2, c=3,): # alloweddef f(*args,): # disalloweddef f(**kwargs,): # disalloweddef f(*, a, b, c,): # disallowedThe last example is what bothers me. The presence of the star should not affect whether trailing comma is allowed or not. If `f(a, b, c,)` is allowed as a call, it should be allowed in a definition, and if def `f(a, b, c,)` is allowed, `f(*, a, b, c,)` should be allowed as well.In the grammar this corresponds to `typedargslist` for functions and `varargslist` for lambdas.• A traling comma is allowed in tuples, lists, dicts, sets, the corresponding comprehensions, augmented assignments, and subscripts. It is also allowed in `from module import names` in the names part, but only if there are surrounding parentheses. Also a trailing semicolon is allowed for multiple statements in one line.• A traling comma is *not* allowed in with statement, `import modules`, assert statement (there is just optional second argument), global and nonlocal statements. In all these cases surrounding parentheses are not allowed.

I'm +1 on adding this. I don't believe it requires a PEP. A trailing comma in definitions is already supported in some places, so I don't buy the argument that it catches errors. During the moratorium we were perhaps too strict.

New changeset419ceb531bab by Robert Collins in branch 'default':Issue#9232: Support trailing commas in function declarations.https://hg.python.org/cpython/rev/419ceb531bab

The patch had some conflicts in the reference docs, I think I resolved it correctly: if someone wanted to cross check my work that would be great. However I was feeling (perhaps wrongly :)) confident so I have committed it as-is.

Do we want to allow a trailing comma after *args or **kwargs in a function definition? Unlike in a call, **kwargs is always the last thing in the list and nothing can be added after that. Just asking.

WithPEP 448, we can now have    fronkulate(**kwargs, **kwargs2)

To be explicit, yes, I want to allow trailing comma even after *args or **kwds. And that's what the patch does.

New changeset6db349fac3ec by Terry Jan Reedy in branch 'default':Issue#9232: Escape rst markup char in NEWS entry to avoid Sphinx warning.https://hg.python.org/cpython/rev/6db349fac3ec