Python line length resolution

Data Management DM Notifications
#1

RFC-107 proposing that Python docstrings be limited to 79 characters was flagged recently as not achieving consensus.

Given that there appears to be no readily-available tool to distinguish between docstring line length and code line length, having an enforced rule as requested by this RFC seems to become a question of whether to limit all code lines to 79 characters.

Given that the rest of the community appears to have standardized at 79 and can live with that, I decreed today, using my authority over coding standards, that as we go to numpydoc and/or auto-format existing code that we will conform to basic PEP 8 in this respect and rescind the 110 character line length for all Python code, not just docstrings. Immediate compliance is not required; it will apply after code has been re-wrapped in the course of redoing documentation. “Style changes must be encapsulated in a distinct commit” continues to apply.

I thought about a “readability” exception, but to facilitate automated tools, it would have to be marked with #noqa, which would only further increase the already-long line length by 6 characters.

This decision may seem abrupt, particularly with regard to the application to all code, but it seemed that no consensus would have been reached there, either, and I had already seen many arguments for longer code line lengths. The decision is final for now. After we have seen how it affects us for a year or so, we can think about revisiting it.

4 Likes
#2

@ktl and I talked about how to implement this standard (note, the RFC is only accepted at this time, not implemented, meaning that the rule isn’t in effect).

It’s clear that we want to use a tool like autopep8 to accelerate the reformatting effort so we don’t have mixed standards in the codebase. At the same time, we also have a second RFC that will broadly change the Python codebase in RFC-214 (docstrings are numpydoc). It’s likely that an autopep8 fix to source line lengths will be more effective if we first migrate docstrings to the new standard.

In DM-9015 we propose a tool that SQuaRE can build to take care of most docstring reformatting work. It’ll be like an autopep8-for-docstrings.

SQuaRE’s current plan is to build this tool before the Joint Technical Meeting in March. Then at the March meeting we can all work together and migrate our packages to the new standards in one swift action. This preparation puts us in a good position to also use some JTM hack time to work together on improving our docstrings.