classification
Title: Allow trailing comma in any function argument list.
Type: enhancement Stage: resolved
Components: Interpreter Core Versions: Python 3.6
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Drekin, Trundle, belopolsky, eric.smith, g.starck@gmail.com, gvanrossum, larry, loewis, mark.dickinson, martin.panter, ncoghlan, pconnell, python-dev, rbcollins, rhettinger, zuo
Priority: normal Keywords: after moratorium

Created on 2010-07-12 14:30 by mark.dickinson, last changed 2015-10-04 03:03 by python-dev. This issue is now closed.

Files
File name Uploaded Description Edit
trailing_commas.patch mark.dickinson, 2010-07-12 18:37 review
trailing_commas2.patch mark.dickinson, 2010-07-22 17:16 review
Messages (30)
msg110089 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-07-12 14:30
Python's current grammar allows a trailing comma after the argument list in:

def f(a, b,):
    pass

but not in

def f(*, a, b,):
    pass

I propose allowing trailing commas in both situations.

See python-dev discussion starting at

http://mail.python.org/pipermail/python-dev/2010-July/101636.html
msg110122 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-07-12 18:37
Here's a patch.  I've checked with PEP 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.
msg110143 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2010-07-12 21:24
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?
msg110161 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-07-13 08:37
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?
msg111194 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-07-22 17:13
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 in Grammar/Grammar, and also updates the production list given in the docs for function definitions.
msg123829 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-12-12 07:55
Retargetting, as this falls under the moratorium, and also because 3.2b1 has been released.
msg123851 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-12-12 20:52
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).
msg123896 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-12-13 19:59
> 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".
msg123906 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-12-13 22:42
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.
msg123909 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2010-12-13 23:56
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.
msg123910 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2010-12-13 23:59
From 10682: the grammar is also inconsistent as to when trailing commas are allowed in function calls, not just definitions.
msg123915 - (view) Author: Jan Kaliszewski (zuo) Date: 2010-12-14 01:37
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).
msg123917 - (view) Author: Jan Kaliszewski (zuo) Date: 2010-12-14 01:44
python-dev discussion continuation: http://mail.python.org/pipermail/python-dev/2010-December/106770.html
msg224470 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2014-08-01 06:36
Moratorium's long over.  Will this patch rise from the dead?
msg224488 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2014-08-01 11:43
> 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.
msg239081 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2015-03-24 00:50
See also Issue 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 confusing
print(1, 2, *(3, 4), end=".\n")  # Better; also suported
print(1, 2, **dict(sep="-"), end=".\n")  # Unsupported, but would be nice
print(end=".\n", 1, 2)  # Unsupported, for good reason

Maybe some of this is covered by Issue 2292 (generalizing * unpacking), but I haven’t been following that, so I’m not sure.
msg239084 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2015-03-24 01:07
It looks like if it was not for Raymond's mild dissent, [1], we would
have a consensus last time this was raised on python-dev, [2-7].

[1] -? Raymond Hettinger https://mail.python.org/pipermail/python-dev/2010-December/106782.html
[2] +0 Guido van Rossum https://mail.python.org/pipermail/python-dev/2010-December/106780.html
[3] +0.5 Alexander Belopolsky https://mail.python.org/pipermail/python-dev/2010-December/106782.html
[4] +1 Antoine Pitrou https://mail.python.org/pipermail/python-dev/2010-December/106783.html
[5] +1 Glenn Linderman https://mail.python.org/pipermail/python-dev/2010-December/106784.html
[6] +1 Cameron Simpson https://mail.python.org/pipermail/python-dev/2010-December/106788.html
[7] +1 Terry Reedy https://mail.python.org/pipermail/python-dev/2010-December/106789.html
msg239085 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2015-03-24 01:12
.. and a couple more -1's on the tracker:

msg123851 - Martin v. Löwis
msg123848 - Brett Cannon

It looks like a round on python-ideas is needed before this can move forward.
msg239797 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2015-04-01 12:44
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>
msg246697 - (view) Author: Grégory Starck (g.starck@gmail.com) * Date: 2015-07-13 18:44
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,
msg247032 - (view) Author: Adam Bartoš (Drekin) * Date: 2015-07-21 13:13
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 # SyntaxError
def f(*, ): pass # SyntaxError
def f(*, a, ): pass # SyntaxError
def f(*, a=2, ): pass # SyntaxError

def f(a, ): pass # Ok
def f(, ): pass # SyntaxError – this should probably stay error

Corresponding calls:
f(*args, ) # Ok
f(*args, a, ) # Ok
f(*args, a=2, ) # Ok 

f(a, ) # Ok
f(, ) # SyntaxError – this is why the corresponding def behavior should stay

My use case:
def f(*, 
        long = 1, 
        list = 2, 
        of = 3, 
        kwonly = 4, 
        parameters = 5, 
    ):
    ...
msg247150 - (view) Author: Robert Collins (rbcollins) * (Python committer) Date: 2015-07-22 20:22
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.
msg248399 - (view) Author: Adam Bartoš (Drekin) * Date: 2015-08-11 10:21
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,): # allowed
def f(a=1, b=2, c=3,): # allowed
def f(*args,): # disallowed
def f(**kwargs,): # disallowed
def f(*, a, b, c,): # disallowed
The 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.
msg248411 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2015-08-11 15:22
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.
msg248425 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2015-08-11 20:00
New changeset 419ceb531bab by Robert Collins in branch 'default':
Issue #9232: Support trailing commas in function declarations.
https://hg.python.org/cpython/rev/419ceb531bab
msg248426 - (view) Author: Robert Collins (rbcollins) * (Python committer) Date: 2015-08-11 20:01
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.
msg248427 - (view) Author: Adam Bartoš (Drekin) * Date: 2015-08-11 20:18
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.
msg248430 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2015-08-11 21:44
With PEP 448, we can now have

    fronkulate(**kwargs, **kwargs2)
msg248449 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2015-08-12 06:38
To be explicit, yes, I want to allow trailing comma even after *args or **kwds. And that's what the patch does.
msg252252 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2015-10-04 03:03
New changeset 6db349fac3ec 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
History
Date User Action Args
2015-10-04 03:03:41python-devsetmessages: + msg252252
2015-08-12 06:38:23gvanrossumsetmessages: + msg248449
2015-08-11 21:44:03larrysetmessages: + msg248430
2015-08-11 20:18:19Drekinsetmessages: + msg248427
2015-08-11 20:01:47rbcollinssetstatus: open -> closed
resolution: fixed
messages: + msg248426

stage: commit review -> resolved
2015-08-11 20:00:34python-devsetnosy: + python-dev
messages: + msg248425
2015-08-11 15:22:43gvanrossumsetnosy: + gvanrossum
messages: + msg248411
2015-08-11 10:21:42Drekinsetmessages: + msg248399
2015-07-22 20:22:03rbcollinssetnosy: + rbcollins

messages: + msg247150
versions: + Python 3.6, - Python 3.5
2015-07-21 13:13:56Drekinsetnosy: + Drekin
messages: + msg247032
2015-07-21 12:53:37martin.panterlinkissue24677 superseder
2015-07-13 18:44:31g.starck@gmail.comsetnosy: + g.starck@gmail.com
messages: + msg246697
2015-07-09 21:01:09r.david.murraylinkissue24600 superseder
2015-04-01 12:44:13martin.pantersetmessages: + msg239797
2015-03-24 01:12:02belopolskysetmessages: + msg239085
2015-03-24 01:07:00belopolskysetnosy: + rhettinger
messages: + msg239084
2015-03-24 00:50:48martin.pantersetmessages: + msg239081
2014-08-01 11:43:27mark.dickinsonsetmessages: + msg224488
2014-08-01 06:36:26larrysetnosy: + larry
messages: + msg224470
2014-07-09 18:21:24pconnellsetnosy: + pconnell
2014-02-26 10:32:18martin.pantersetnosy: + martin.panter
2014-01-31 22:05:49yselivanovsetversions: + Python 3.5, - Python 3.3
2012-10-25 07:51:34chris.jerdoneklinkissue16319 superseder
2012-03-10 18:34:32mark.dickinsonsetassignee: mark.dickinson ->
2010-12-14 01:49:59Trundlesetnosy: + Trundle
2010-12-14 01:44:21zuosetmessages: + msg123917
2010-12-14 01:37:18zuosetmessages: + msg123915
2010-12-14 01:10:11eric.smithsetnosy: + eric.smith
2010-12-13 23:59:20ncoghlansetmessages: + msg123910
2010-12-13 23:57:44ncoghlanlinkissue10682 superseder
2010-12-13 23:56:33ncoghlansetstatus: closed -> open
keywords: + after moratorium, - patch
resolution: rejected -> (no value)
messages: + msg123909
2010-12-13 22:42:41loewissetmessages: + msg123906
2010-12-13 19:59:21belopolskysetnosy: + belopolsky
messages: + msg123896
2010-12-13 11:07:46zuosetnosy: + zuo
2010-12-12 20:52:56loewissetstatus: open -> closed
resolution: rejected
messages: + msg123851
2010-12-12 10:40:16ncoghlansetstage: needs patch -> commit review
2010-12-12 07:55:32loewissetnosy: + loewis

messages: + msg123829
versions: + Python 3.3, - Python 3.2
2010-07-22 17:16:10mark.dickinsonsetfiles: - trailing_commas2.patch
2010-07-22 17:16:05mark.dickinsonsetfiles: + trailing_commas2.patch
2010-07-22 17:13:47mark.dickinsonsetfiles: + trailing_commas2.patch

messages: + msg111194
2010-07-20 12:32:08mark.dickinsonsetassignee: mark.dickinson
2010-07-13 08:37:15mark.dickinsonsetmessages: + msg110161
2010-07-12 21:24:31ncoghlansetnosy: + ncoghlan
messages: + msg110143
2010-07-12 18:37:30mark.dickinsonsetfiles: + trailing_commas.patch
keywords: + patch
messages: + msg110122
2010-07-12 14:30:16mark.dickinsoncreate