Issue37813
Created on 2019-08-10 21:46 by maggyero, last changed 2019-08-13 18:06 by gvanrossum. This issue is now closed.
Messages (4) | |||
---|---|---|---|
msg349361 - (view) | Author: Géry (maggyero) * | Date: 2019-08-10 21:46 | |
I have just read PEP 7 and noticed that its line-breaking recommandation in presence of binary operations seems to contradict its analogue in PEP 8 which follows Knuth's rule. PEP 7 (https://www.python.org/dev/peps/pep-0007/#code-lay-out): > When you break a long expression at a binary operator, the operator > goes at the end of the previous line, and braces should be formatted > as shown. E.g.: > > if (type->tp_dictoffset != 0 && base->tp_dictoffset == 0 && > type->tp_dictoffset == b_size && > (size_t)t_size == b_size + sizeof(PyObject *)) > { > return 0; /* "Forgive" adding a __dict__ only */ > } PEP 8 (https://www.python.org/dev/peps/pep-0008/#should-a-line-break-before-or-after-a-binary-operator): > To solve this readability problem, mathematicians and their > publishers follow the opposite convention. Donald Knuth explains the > traditional rule in his Computers and Typesetting series: "Although > formulas within a paragraph always break after binary operations and > relations, displayed formulas always break before binary operations" > [3]. > > Following the tradition from mathematics usually results in more > readable code: > > # Yes: easy to match operators with operands > income = (gross_wages > + taxable_interest > + (dividends - qualified_dividends) > - ira_deduction > - student_loan_interest) > In Python code, it is permissible to break before or after a binary > operator, as long as the convention is consistent locally. For new > code Knuth's style is suggested. |
|||
msg349586 - (view) | Author: Barry A. Warsaw (barry) * ![]() |
Date: 2019-08-13 17:17 | |
I personally don't think we need to change this. C and Python are different, and the PEP 7 rules have been in place for ages. +Guido |
|||
msg349587 - (view) | Author: Serhiy Storchaka (serhiy.storchaka) * ![]() |
Date: 2019-08-13 17:27 | |
PEP 8 contains contradictory examples. https://www.python.org/dev/peps/pep-0008/#indentation > # No extra indentation. > if (this_is_one_thing and > that_is_another_thing): > do_something() > > # Add a comment, which will provide some distinction in editors > # supporting syntax highlighting. > if (this_is_one_thing and > that_is_another_thing): > # Since both conditions are true, we can frobnicate. > do_something() > > # Add some extra indentation on the conditional continuation line. > if (this_is_one_thing > and that_is_another_thing): > do_something() > > (Also see the discussion of whether to break before or after binary > operators below.) (It was already reported in other issue.) |
|||
msg349595 - (view) | Author: Guido van Rossum (gvanrossum) * ![]() |
Date: 2019-08-13 18:06 | |
PEP 8 intentionally allows users to choose whether to put the operator at the start or end of the line (as long as they're consistent within a file or project). This is to avoid a barrage of "style fixes" that are just noise. But PEP 7 is only for CPython's own C code style, and here I don't want things to change. When it comes to readability of our code surely there are bigger fish to fry. So I'm closing this as won't fix. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2019-08-13 18:06:09 | gvanrossum | set | status: open -> closed resolution: wont fix messages: + msg349595 stage: resolved |
2019-08-13 17:28:10 | serhiy.storchaka | set | versions: - Python 3.7 |
2019-08-13 17:27:48 | serhiy.storchaka | set | nosy:
+ serhiy.storchaka messages: + msg349587 |
2019-08-13 17:17:46 | barry | set | nosy:
+ gvanrossum messages: + msg349586 |
2019-08-13 17:11:35 | brett.cannon | set | nosy:
+ barry |
2019-08-10 21:46:12 | maggyero | create |