classification
Title: PEP 7 line-breaking with binary operations contradicts Knuth's rule
Type: enhancement Stage: resolved
Components: Documentation Versions:
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: docs@python Nosy List: barry, docs@python, gvanrossum, maggyero, serhiy.storchaka
Priority: normal Keywords:

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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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:09gvanrossumsetstatus: open -> closed
resolution: wont fix
messages: + msg349595

stage: resolved
2019-08-13 17:28:10serhiy.storchakasetversions: - Python 3.7
2019-08-13 17:27:48serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg349587
2019-08-13 17:17:46barrysetnosy: + gvanrossum
messages: + msg349586
2019-08-13 17:11:35brett.cannonsetnosy: + barry
2019-08-10 21:46:12maggyerocreate