What about adding rule about trailing comma?
Yes:
foo(aaa, bbb)
or
foo(aaa, bbb, )
No:
foo(aaa, bbb,) # except one-value tuple.
or
foo(aaa, bbb )
On Mar 30, 2015, at 23:35, INADA Naoki songofacandy@gmail.com wrote:
What about adding rule about trailing comma?
I don't understand the proposed rule from your example. Are you suggesting that a trailing comma be a syntax error unless it's following by a newline? That would explain both "yesses" and the first "no", but then what's wrong with the second "no"? You can always add newlines in the middle of any parenthesized expression; are you suggesting that you shouldn't be allowed to add one at the very end, unless it's immediately following a comma? If so, why?
Also, you seem to realize you're adding a gratuitous inconsistency with one-element tuples. Haven't they been through enough teasing without having to make them even more different?
Most of all, whatever your actual rule is: Why? What's the intended benefit here?
Yes:
foo(aaa, bbb)
or
foo(aaa, bbb, )
No:
foo(aaa, bbb,) # except one-value tuple.
or
foo(aaa, bbb )
-- INADA Naoki songofacandy@gmail.com _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Tue, Mar 31, 2015 at 4:30 PM, Andrew Barnert abarnert@yahoo.com wrote:
On Mar 30, 2015, at 23:35, INADA Naoki songofacandy@gmail.com wrote:
What about adding rule about trailing comma?
I don't understand the proposed rule from your example. Are you suggesting that a trailing comma be a syntax error unless it's following by a newline?
I'm sorry, I meant about adding rule to PEP 8. Not Python syntax.
That would explain both "yesses" and the first "no", but then what's wrong with the second "no"? You can always add newlines in the middle of any parenthesized expression; are you suggesting that you shouldn't be allowed to add one at the very end, unless it's immediately following a comma? If so, why?
Also, you seem to realize you're adding a gratuitous inconsistency with one-element tuples. Haven't they been through enough teasing without having to make them even more different?
Most of all, whatever your actual rule is: Why? What's the intended benefit here?
I recently write Go program more than Python. I feel good about line continuation rule in Go: Some characters including comma means line continuation.
Benefit of this style is:
1) More consistent 2) No garbage diff just for just adding comma
Yes:
foo(aaa, bbb)
or
foo(aaa, bbb, )
No:
foo(aaa, bbb,) # except one-value tuple.
or
foo(aaa, bbb )
-- INADA Naoki songofacandy@gmail.com _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Tue, Mar 31, 2015 at 7:28 PM, INADA Naoki songofacandy@gmail.com wrote:
Benefit of this style is:
- More consistent
- No garbage diff just for just adding comma
So what you have there is a good reason for adopting this style. Is there strong reason for mentioning it in PEP 8? Remember, every recommendation in a style guide has a cost - too many rules and it just becomes onerous, not to mention the increased likelihood of the rule giving the wrong advice in some corner case (which leads intelligent people to disregard the rule, and unintelligent checkers to spew warnings which then have to be ignored - this is one of the fundamental difficulties of scripting PEP 8 or any other style guide); ideally, trust people to be intelligent, and don't enforce more than you have to.
ChrisA
One good parts of Go is gofmt, the standard code formatter. It makes learning Go more easy and fun. New Gophers can learn Go without learning coding style which gofmt handles.
Python doesn't have standard code formatter like gofmt, but there are some third party checkers and formatters including pep8.py, autopep8 and google/yapf. There are also formmatters integrated in IDEs.
My concern is defining good edge cases for code formatter developers. So my real question was: How many people prefer (or dislike) this rule is in code formatter?
If many people prefer this, could we have standard "Style guide for code formatter developers" for rules too verbose to include PEP 8?
On Tuesday, March 31, 2015 at 5:34:40 PM UTC+9, Chris Angelico wrote:
On Tue, Mar 31, 2015 at 7:28 PM, INADA Naoki <songof...@gmail.com javascript:> wrote:
Benefit of this style is:
- More consistent
- No garbage diff just for just adding comma
So what you have there is a good reason for adopting this style. Is there strong reason for mentioning it in PEP 8? Remember, every recommendation in a style guide has a cost - too many rules and it just becomes onerous, not to mention the increased likelihood of the rule giving the wrong advice in some corner case (which leads intelligent people to disregard the rule, and unintelligent checkers to spew warnings which then have to be ignored - this is one of the fundamental difficulties of scripting PEP 8 or any other style guide); ideally, trust people to be intelligent, and don't enforce more than you have to.
ChrisA _______________________________________________ Python-ideas mailing list Python...@python.org javascript: https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Tue, Mar 31, 2015 at 5:35 PM, INADA Naoki songofacandy@gmail.com wrote:
What about adding rule about trailing comma?
My crystal ball tells me that you're possibly talking about PEP 8 rather than about actual language changes. Is that correct?
There's absolutely no need to put restrictions like this into the language itself. If the trailing comma is permitted, it should be permitted whether there's a newline after it or not.
In your own style guide, you're most welcome to advocate what you will, without needing any approval from the Python core devs. If you want to say, for instance, "we follow PEP 8, with the following additional requirements", and then list your trailing comma rule and any others you want to require, people will understand. Actually, most people will do something like this, anyway.
ChrisA
participants (4)
-
Andrew Barnert -
Chris Angelico -
INADA Naoki -
Naoki INADA