On Tue, Mar 31, 2015 at 4:30 PM, Andrew Barnert wrote:

On Mar 30, 2015, at 23:35, INADA Naoki 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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

-- INADA Naoki

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 javascript:> wrote:

...

Benefit of this style is:

1) More consistent 2) 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/