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'
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.
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 in Grammar/Grammar, and also updates the production list given in the docs for function definitions.
loewis commented on Dec 12, 2010
loewismannequin
Mannequin
More actions
Retargetting, as this falls under the moratorium, and also because 3.2b1 has been released.
loewis commented on Dec 12, 2010
loewismannequin
Mannequin
More actions
In bpo-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 bpo-10682, several committers indicated that they would prefer
not to change this.
Issue bpo-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 bpo-10682 should have been closed as a duplicate of this issue and this issue should be marked as "after moratorium".
loewis commented on Dec 13, 2010
loewismannequin
Mannequin
More actions
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.
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
mdickinson commentedon Jul 12, 2010
Python's current grammar allows a trailing comma after the argument list in:
but not in
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
mdickinson commentedon Jul 12, 2010
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.
ncoghlan commentedon Jul 12, 2010
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?
mdickinson commentedon Jul 13, 2010
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?
mdickinson commentedon Jul 22, 2010
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.
loewis commentedon Dec 12, 2010
Retargetting, as this falls under the moratorium, and also because 3.2b1 has been released.
loewis commentedon Dec 12, 2010
In bpo-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).
abalkin commentedon Dec 13, 2010
Issue bpo-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 bpo-10682 should have been closed as a duplicate of this issue and this issue should be marked as "after moratorium".
loewis commentedon Dec 13, 2010
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.
ncoghlan commentedon Dec 13, 2010
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.
8 remaining items
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