Uploaded image for project: 'Request For Comments'
  1. Request For Comments
  2. RFC-650

Change our Python standard to put binary operators at the beginning of a continuation line

    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

            Activity

            Hide
            ktl Kian-Tat Lim added a comment -

            I'm fine with this.

            Show
            ktl Kian-Tat Lim added a comment - I'm fine with this.
            Hide
            jbosch Jim Bosch added a comment -

            Show
            jbosch Jim Bosch added a comment -
            Hide
            price 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.

            Show
            price 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.
            Hide
            swinbank John Swinbank added a comment -

            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.

            Show
            swinbank John Swinbank added a comment - 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.
            Hide
            rowen Russell Owen added a comment - - edited

            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).

            Show
            rowen Russell Owen added a comment - - edited 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).
            Hide
            rowen Russell Owen added a comment - - edited

            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.

            Show
            rowen Russell Owen added a comment - - edited 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.
            Hide
            ktl Kian-Tat Lim added a comment - - edited

            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.

            Show
            ktl Kian-Tat Lim added a comment - - edited 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.
            Hide
            rowen Russell Owen added a comment -

            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.

            Show
            rowen Russell Owen added a comment - 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.

              People

              • Assignee:
                rowen Russell Owen
                Reporter:
                rowen Russell Owen
                Watchers:
                Ian Sullivan, Jim Bosch, John Parejko, John Swinbank, Kian-Tat Lim, Russell Owen, Tim Jenness
              • Votes:
                0 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Planned End: