PEP needed for http://bugs.python.org/issue9232 ?

So, there's a patch on issue 9232 - allow trailing commas in function definitions - but there's been enough debate that I suspect we need a PEP. Would love it if someone could correct me, but I'd like to be able to either categorically say 'no' and close the ticket, or 'yes and this is what needs to happen next'. -Rob -- Robert Collins <rbtcollins@hp.com> Distinguished Technologist HP Converged Cloud

On Tue, 11 Aug 2015 18:09:34 +1200, Robert Collins <robertc@robertcollins.net> wrote:
I think we might just need another round of discussion here. I'm +1 myself. Granted there haven't been many times I've wanted it (functions with enough arguments to want to make it easy to add and remove elements are a bit of a code smell), but I have wanted it (and even used the form that is accepted) several times. On the other hand, the number of times when the detection of a trailing comma has revealed a missing argument to me (Raymond's objection) has been...well, I'm pretty sure it is zero. Especially since it only happens *sometimes*. Since backward compatibility says we shouldn't disallow it where it is currently allowed, the only logical thing to do, IMO, is consistently allow it. (If you wanted to fix an 'oops' trailing comma syntax issue, I'd vote for disallowing trailing commas outside of (). The number of times I've ended up with an unintentional tuple after converting a dictionary to a series of assignments outnumbers both of the above :) Note, I am *not* suggesting doing this!) --David

On Wed, Aug 12, 2015 at 12:46 AM, R. David Murray <rdmurray@bitdance.com> wrote:
Outside of any form of bracket, I hope you mean. The ability to leave a trailing comma on a list or dict is well worth keeping: func = { "+": operator.add, "-": operator.sub, "*": operator.mul, "/": operator.truediv, } ChrisA

On Wed, 12 Aug 2015 01:03:38 +1000, Chris Angelico <rosuav@gmail.com> wrote:
Sorry, "trailing comma outside ()" was a shorthand for 'trailing comma on a complete statement'. That is, what trips me up is going from something like: dict(abc=1, foo=2, bar=3, ) to: abc = 1, foo = 2, bar = 3, That is, I got rid of the dict(), but forgot to delete the commas. (Real world examples are more complex and it is often that the transformation gets done piecemeal and/or via cut and paste and I only miss one or two of the commas... But, for backward compatibility reasons, we wouldn't change it even if everyone thought it was a good idea for some reason :) --David

On Wed, Aug 12, 2015 at 3:01 AM, R. David Murray <rdmurray@bitdance.com> wrote:
Sure. In that case, I agree with you completely. When I *do* want a tuple, I'll usually be putting it inside parens, rather than just tagging a comma on. But this can be the job of a linter. ChrisA

Please no :-) Looking back at the previous discussion, it looked like it's all been said, and there was almost unanimous approval (with some key mild disapproval) for the idea, so what we need now is a pronouncement. If it's unclear whether consensus was close, then folks that are strongly against should speak up now. If there is a flurry of those, then a PEP is in order. But another big long unstructured discussion won't be useful. -Chris

On Tue, 11 Aug 2015 18:09:34 +1200, Robert Collins <robertc@robertcollins.net> wrote:
I think we might just need another round of discussion here. I'm +1 myself. Granted there haven't been many times I've wanted it (functions with enough arguments to want to make it easy to add and remove elements are a bit of a code smell), but I have wanted it (and even used the form that is accepted) several times. On the other hand, the number of times when the detection of a trailing comma has revealed a missing argument to me (Raymond's objection) has been...well, I'm pretty sure it is zero. Especially since it only happens *sometimes*. Since backward compatibility says we shouldn't disallow it where it is currently allowed, the only logical thing to do, IMO, is consistently allow it. (If you wanted to fix an 'oops' trailing comma syntax issue, I'd vote for disallowing trailing commas outside of (). The number of times I've ended up with an unintentional tuple after converting a dictionary to a series of assignments outnumbers both of the above :) Note, I am *not* suggesting doing this!) --David

On Wed, Aug 12, 2015 at 12:46 AM, R. David Murray <rdmurray@bitdance.com> wrote:
Outside of any form of bracket, I hope you mean. The ability to leave a trailing comma on a list or dict is well worth keeping: func = { "+": operator.add, "-": operator.sub, "*": operator.mul, "/": operator.truediv, } ChrisA

On Wed, 12 Aug 2015 01:03:38 +1000, Chris Angelico <rosuav@gmail.com> wrote:
Sorry, "trailing comma outside ()" was a shorthand for 'trailing comma on a complete statement'. That is, what trips me up is going from something like: dict(abc=1, foo=2, bar=3, ) to: abc = 1, foo = 2, bar = 3, That is, I got rid of the dict(), but forgot to delete the commas. (Real world examples are more complex and it is often that the transformation gets done piecemeal and/or via cut and paste and I only miss one or two of the commas... But, for backward compatibility reasons, we wouldn't change it even if everyone thought it was a good idea for some reason :) --David

On Wed, Aug 12, 2015 at 3:01 AM, R. David Murray <rdmurray@bitdance.com> wrote:
Sure. In that case, I agree with you completely. When I *do* want a tuple, I'll usually be putting it inside parens, rather than just tagging a comma on. But this can be the job of a linter. ChrisA

Please no :-) Looking back at the previous discussion, it looked like it's all been said, and there was almost unanimous approval (with some key mild disapproval) for the idea, so what we need now is a pronouncement. If it's unclear whether consensus was close, then folks that are strongly against should speak up now. If there is a flurry of those, then a PEP is in order. But another big long unstructured discussion won't be useful. -Chris
participants (6)
-
Alexander Walters
-
Chris Angelico
-
Chris Barker - NOAA Federal
-
Guido van Rossum
-
R. David Murray
-
Robert Collins