You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Allow trailing comma in any function argument list. #53478
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=<Date2015-08-11.20:01:47.555>created_at=<Date2010-07-12.14:30:16.029>labels= ['interpreter-core', 'type-feature']
title='Allow trailing comma in any function argument list.'updated_at=<Date2015-10-04.03:03:41.342>user='https://github.com/mdickinson'
From 10682: the grammar is also inconsistent as to when trailing commas are allowed in function calls, not just definitions.
zuo commented on Dec 14, 2010
zuomannequin
Mannequin
More actions
From 10682: The patch proposed in this (bpo-9232) issue does not fix call syntax but def sytax only. I think it should fix call sytax as well (see code examples in bpo-10682).
See also bpo-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 reason
Maybe some of this is covered by bpo-2292 (generalizing * unpacking), but I haven’t been following that, so I’m not sure.
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.
Drekin commented on Aug 11, 2015
Drekinmannequin
Mannequin
More actions
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.
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.
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.
Activity
ncoghlan commentedon Dec 13, 2010
From 10682: the grammar is also inconsistent as to when trailing commas are allowed in function calls, not just definitions.
zuo commentedon Dec 14, 2010
From 10682: The patch proposed in this (bpo-9232) issue does not fix call syntax but def sytax only. I think it should fix call sytax as well (see code examples in bpo-10682).
zuo commentedon Dec 14, 2010
python-dev discussion continuation: http://mail.python.org/pipermail/python-dev/2010-December/106770.html
larryhastings commentedon Aug 1, 2014
Moratorium's long over. Will this patch rise from the dead?
mdickinson commentedon Aug 1, 2014
It's really down to getting consensus that it's a good idea. That might require another python-dev discussion.
vadmium commentedon Mar 24, 2015
See also bpo-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:
Maybe some of this is covered by bpo-2292 (generalizing * unpacking), but I haven’t been following that, so I’m not sure.
abalkin commentedon Mar 24, 2015
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
abalkin commentedon Mar 24, 2015
.. 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.
vadmium commentedon Apr 1, 2015
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\>
gst commentedon Jul 13, 2015
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,
Drekin commentedon Jul 21, 2015
Reposting from from my newest duplicate of this issue (bpo-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
Corresponding calls:
f(*args, ) # Ok
f(*args, a, ) # Ok
f(*args, a=2, ) # Ok
My use case:
def f(*,
long = 1,
list = 2,
of = 3,
kwonly = 4,
parameters = 5,
):
...
rbtcollins commentedon Jul 22, 2015
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.
Drekin commentedon Aug 11, 2015
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 deff(a, b, c,)is allowed,f(*, a, b, c,)should be allowed as well.In the grammar this corresponds to
typedargslistfor functions andvarargslistfor 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 namesin 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.gvanrossum commentedon Aug 11, 2015
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.
python-dev commentedon Aug 11, 2015
New changeset 419ceb531bab by Robert Collins in branch 'default':
Issue bpo-9232: Support trailing commas in function declarations.
https://hg.python.org/cpython/rev/419ceb531bab
rbtcollins commentedon Aug 11, 2015
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.
Drekin commentedon Aug 11, 2015
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.
larryhastings commentedon Aug 11, 2015
With PEP-448, we can now have
gvanrossum commentedon Aug 12, 2015
To be explicit, yes, I want to allow trailing comma even after *args or **kwds. And that's what the patch does.
python-dev commentedon Oct 4, 2015
New changeset 6db349fac3ec by Terry Jan Reedy in branch 'default':
Issue bpo-9232: Escape rst markup char in NEWS entry to avoid Sphinx warning.
https://hg.python.org/cpython/rev/6db349fac3ec