Details
-
Type:
RFC
-
Status: Implemented
-
Resolution: Done
-
Component/s: DM
-
Labels:None
-
Location:This ticket
Description
Our current Python coding standard is to break long lines at a binary operator by having the binary operator at the end of the line. I propose to change this, for two reasons:
- The puts a critical piece of information (the binary operator) first, where it is easy to see and not lost in a sea of text.
- It matches what "black" does. So if we start formatting any of our packages with "black" the results will look familiar. (see
RFC-649).
My proposed means of adoption is:
- Change one package at a time, as time permits and people have inclination.
- Change a package by first changing setup.cfg to suppress W503 instead of W504 (they are complementary), then fixing any flake8 warnings.
I believe that continuation lines are rare enough and that existing code is readable enough, that there is no rush on making this change. I envision it as something someone might choose to do if one is already editing a package.
Attachments
Issue Links
- is triggering
-
- Done
-
- Done
-
DM-23173 Implement RFC-650: update packages to prefer binary operators at the beginning of continued lines
- Done
- relates to
-
- Done
-
- Withdrawn
Activity
I'm very much against this. Putting the operator at the end of the line signals that the line is not complete.
Paul Price
added a comment - I'm very much against this. Putting the operator at the end of the line signals that the line is not complete. Let's not change existing conventions now. Adopting this in new code only will make it inconsistent with old code; changing old code wastes time and makes history hard to follow. Neither of those are desirable unless necessary to address a critical need, which isn't the case here.
Paul Price pyflakes doesn't allow a continued line to have the same indentation as lines that follow; so this is not allowed:
if foo == bar \
|
and baz = something_else:
|
# do some stuff here
|
Instead one has to write something like this:
if foo == bar \
|
and baz = something_else:
|
# do some stuff here
|
which to my eyes makes it very clear that the line is being continued.
John Swinbank I hear you. I would, however, like to point out that it will not affect very much code and (in my opinion) increases readability. I am willing to do the work to update our packages (and setup.cfg files, which will make sure the new standard is followed).
John Swinbank if I do the work are you willing to accept this change? My proposed plan is:
- Make a list of all packages.
- For each package update the flake8 configuration.
- Run flake8 and fix any issues.
If you are OK with that I am going to mark it approved.
Pace Paul Price, I think the PEP 8 change in 2016 to break before rather than after the operator is clearly where the future is. Aside from the readability arguments made for that change, including Knuth's opinion, the prevalence of method chaining in APIs (with ".", while formally a delimiter, serving effectively as an operator) is also pushing in this direction. Breaking before is also a long-standing convention for logical operators like "AND" and "OR" in SQL statements.
But flake8 allows line breaks before "." even when binary operators have line breaks after, as is currently the case in our code. So the question really comes down to the cost of inconsistency and the cost of change.
The cost of inconsistency is relatively small; we're living with it today. But given the desire to be consistent with the Python community and coding community in general, my bias is to allow the change if the cost can be made trivial.
Changing every package's setup.cfg file in the absence of other changes, triggering a rebuild/retag for no reason, is undesirable. (It's a shame that our flake8 configuration can't be more centralized.) Changing a package's flake8 configuration only if other changes are being made and changing line breaks if then shown to be necessary would be acceptable, however, particularly if this is volunteer work by Russell.
So i would suggest that Russell's list and work plan be adopted, but with the additional caveat that he only be allowed to work on packages that have been otherwise modified by anyone after the adoption of this RFC (or perhaps 2020-01-01 as a simple reference point). This is similar to the original proposal to have this be something that is done if one is already editing a package, except that Russell is doing the work.
Adopted as K-T specified in his previous comment.
John Swinbank told me in person he was OK with it if I did the work.
I'm fine with this.