A grammatical oddity: trailing commas in argument lists.
While looking at a parser module issue (http://bugs.python.org/issue9154) I noticed that Python's grammar doesn't permit trailing commas after keyword-only args. That is, def f(a, b,): pass is valid syntax, while def f(*, a, b,): pass is not. I was just curious whether the latter was deliberate or an oversight. And if an oversight, is it worth fixing after the moratorium expires? (See also http://bugs.python.org/issue2009.) Mark
On 7/9/10 10:40 AM, Mark Dickinson wrote:
While looking at a parser module issue (http://bugs.python.org/issue9154) I noticed that Python's grammar doesn't permit trailing commas after keyword-only args. That is,
def f(a, b,): pass
is valid syntax, while
def f(*, a, b,): pass
is not. I was just curious whether the latter was deliberate or an oversight. And if an oversight, is it worth fixing after the moratorium expires? (See also http://bugs.python.org/issue2009.)
I use trailing commas all the time in argument lists. I don't use keyword-only args much, but I will when I switch to 3.x. I'd like to see this fixed. I'd argue it's a bug fix, but that's me. -- Eric.
Am 09.07.2010 18:36, schrieb Eric Smith:
On 7/9/10 10:40 AM, Mark Dickinson wrote:
While looking at a parser module issue (http://bugs.python.org/issue9154) I noticed that Python's grammar doesn't permit trailing commas after keyword-only args. That is,
def f(a, b,): pass
is valid syntax, while
def f(*, a, b,): pass
is not. I was just curious whether the latter was deliberate or an oversight. And if an oversight, is it worth fixing after the moratorium expires? (See also http://bugs.python.org/issue2009.)
I use trailing commas all the time in argument lists. I don't use keyword-only args much, but I will when I switch to 3.x. I'd like to see this fixed. I'd argue it's a bug fix, but that's me.
+1 Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On 7/9/2010 10:40 AM, Mark Dickinson wrote:
While looking at a parser module issue (http://bugs.python.org/issue9154) I noticed that Python's grammar doesn't permit trailing commas after keyword-only args. That is,
def f(a, b,): pass
is valid syntax, while
def f(*, a, b,): pass
is not. I was just curious whether the latter was deliberate or an oversight. And if an oversight, is it worth fixing after the moratorium expires? (See also http://bugs.python.org/issue2009.)
The way I read the grammar in the function definition section of the manual, a trailing comma is only allowed after a 'defparameter' that does not come after a *. In this sense, the above is not a bug. However, while the grammar in the call doc does not allow trailing commas, the following note says "A trailing comma may be present after the positional and keyword arguments but does not affect the semantics." This has the combined effect
def f(*,a): pass
f(a=1) f(a=1,) def f(*,a,): pass SyntaxError: invalid syntax
This violates the important principle that allowed def and call arg sequences should match to the extent sensible and possible. In this sense, the SyntaxError is a bug. So I would fix this now for 3.2 and notify the other implementors. -- Terry Jan Reedy
Terry wrote:
This violates the important principle that allowed def and call arg sequences should match to the extent sensible and possible. In this sense, the SyntaxError is a bug. So I would fix this now for 3.2 and notify the other implementors.
+1 on fixing it - trailing commas are awesome. I'm always annoyed in C# where I frequently can't use them. This seems like a bug fix level change that should be easy for the other implementations to fix.
On Fri, Jul 9, 2010 at 8:37 PM, Dino Viehland <dinov@microsoft.com> wrote:
Terry wrote:
This violates the important principle that allowed def and call arg sequences should match to the extent sensible and possible. In this sense, the SyntaxError is a bug. So I would fix this now for 3.2 and notify the other implementors.
+1 on fixing it - trailing commas are awesome. I'm always annoyed in C# where I frequently can't use them. This seems like a bug fix level change that should be easy for the other implementations to fix.
Thanks for all the feedback. If the grammar is changed to allow "def f(*, a,): pass", that still leaves some more open questions: which of the following should be valid? (1) def f(*args,): pass (2) def f(**kwargs,): pass (3) def f(*,): pass Just for the sake of simplicity it would seem to make sense allow all these, even if there's no obvious immediate use; for me, it keeps the mental footprint of the language small---I don't have to remember when the comma is or isn't allowed. Note that (1) and (2) aren't valid (and never have been, as far as I know) in Python 2.x, though. (Neither is (3), of course, since keyword-only arguments are 3.x only.) (3) is a bit subtle: "def f(*): pass" is actually allowed by the grammar, but produces a SyntaxError later on, when the parse tree is converted to AST: >>> def f(*): pass ... File "<stdin>", line 1 SyntaxError: named arguments must follow bare * So it probably doesn't matter much whether (3) is permitted by the grammar or not. -- Mark
Am 09.07.2010 22:26, schrieb Mark Dickinson:
On Fri, Jul 9, 2010 at 8:37 PM, Dino Viehland <dinov@microsoft.com> wrote:
Terry wrote:
This violates the important principle that allowed def and call arg sequences should match to the extent sensible and possible. In this sense, the SyntaxError is a bug. So I would fix this now for 3.2 and notify the other implementors.
+1 on fixing it - trailing commas are awesome. I'm always annoyed in C# where I frequently can't use them. This seems like a bug fix level change that should be easy for the other implementations to fix.
Thanks for all the feedback.
If the grammar is changed to allow "def f(*, a,): pass", that still leaves some more open questions: which of the following should be valid?
(1) def f(*args,): pass (2) def f(**kwargs,): pass (3) def f(*,): pass
IMO all of them (though as you mention, (3) doesn't matter.) Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On 7/9/2010 4:42 PM, Georg Brandl wrote:
Am 09.07.2010 22:26, schrieb Mark Dickinson:
On Fri, Jul 9, 2010 at 8:37 PM, Dino Viehland<dinov@microsoft.com> wrote:
Terry wrote:
This violates the important principle that allowed def and call arg sequences should match to the extent sensible and possible. In this sense, the SyntaxError is a bug. So I would fix this now for 3.2 and notify the other implementors.
+1 on fixing it - trailing commas are awesome. I'm always annoyed in C# where I frequently can't use them. This seems like a bug fix level change that should be easy for the other implementations to fix.
Thanks for all the feedback.
If the grammar is changed to allow "def f(*, a,): pass", that still leaves some more open questions: which of the following should be valid?
(1) def f(*args,): pass (2) def f(**kwargs,): pass (3) def f(*,): pass
IMO all of them (though as you mention, (3) doesn't matter.)
Agreed. It's one less thing to explain: "You can have a trailing comma in an argument list, unless there's a bare star, and in that case you can't have a comma; and also if ...". Ick. Eric.
On 7/9/2010 4:26 PM, Mark Dickinson wrote:
On Fri, Jul 9, 2010 at 8:37 PM, Dino Viehland<dinov@microsoft.com> wrote:
Terry wrote:
This violates the important principle that allowed def and call arg sequences should match to the extent sensible and possible. In this sense, the SyntaxError is a bug. So I would fix this now for 3.2 and notify the other implementors.
+1 on fixing it - trailing commas are awesome. I'm always annoyed in C# where I frequently can't use them. This seems like a bug fix level change that should be easy for the other implementations to fix.
Thanks for all the feedback.
If the grammar is changed to allow "def f(*, a,): pass", that still leaves some more open questions: which of the following should be valid?
(1) def f(*args,): pass (2) def f(**kwargs,): pass (3) def f(*,): pass
I would follow the same principle of making def and call match. Currently
def f(*args,): pass
SyntaxError: invalid syntax
def f(*args): pass
f(*(1,2,3),) SyntaxError: invalid syntax
Giving the call doc "A trailing comma may be present after the positional and keyword arguments but does not affect the semantics.", I was not really expecting the second syntax error. Same behavior for f(**k,). So if you allow the definition, allow the call too.
Just for the sake of simplicity it would seem to make sense allow all these, even if there's no obvious immediate use; for me, it keeps the mental footprint of the language small---I don't have to remember when the comma is or isn't allowed.
Agreed. -- Terry Jan Reedy
On Sat, Jul 10, 2010 at 5:31 AM, Terry Reedy <tjreedy@udel.edu> wrote:
This violates the important principle that allowed def and call arg sequences should match to the extent sensible and possible. In this sense, the SyntaxError is a bug. So I would fix this now for 3.2 and notify the other implementors.
+1 for fixing it from me, unless any of the other implementations object. @Mark: my comment on the tracker issue had an implied "...unless you really want to" on the end :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sat, Jul 10, 2010 at 1:22 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
+1 for fixing it from me, unless any of the other implementations object.
@Mark: my comment on the tracker issue had an implied "...unless you really want to" on the end :)
Thanks! Patch at http://bugs.python.org/issue9232 Mark
participants (6)
-
Dino Viehland -
Eric Smith -
Georg Brandl -
Mark Dickinson -
Nick Coghlan -
Terry Reedy