[issue19560] PEP 8 operator precedence across parens

2013-11-12 Thread Ezio Melotti
Changes by Ezio Melotti : -- stage: -> committed/rejected ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue19560] PEP 8 operator precedence across parens

2013-11-12 Thread Guido van Rossum
Guido van Rossum added the comment: Style is a matter of taste, not of correctness. It is pointless to debate the finer points in a bug report. -- resolution: -> invalid status: pending -> closed ___ Python tracker

[issue19560] PEP 8 operator precedence across parens

2013-11-12 Thread Ezio Melotti
Ezio Melotti added the comment: See msg173785. The example in the "no" section is not "wrong" -- it's just worse than the one in the "yes" section because it provides less hints about the groups and it's less readable, so it has no reason to be used. If you note the introductory paragraph it

[issue19560] PEP 8 operator precedence across parens

2013-11-12 Thread Barry A. Warsaw
Changes by Barry A. Warsaw : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue19560] PEP 8 operator precedence across parens

2013-11-12 Thread Tom Lynn
Tom Lynn added the comment: FWIW, this pair of examples differs from the others in this section as they were both explicitly okayed in the first version of PEP 8 :: - Use your better judgment for the insertion of spaces around ar

[issue19560] PEP 8 operator precedence across parens

2013-11-12 Thread Tom Lynn
New submission from Tom Lynn: PEP 8 currently has:: Yes:: ... c = (a+b) * (a-b) No:: ... c = (a + b) * (a - b) That looks wrong to me -- surely the parens are a sufficient precedence hint, and don't need further squashing inside? This will be worse with any non-tr