Python style guide
Coding style and best practices for writing Python code for Software Heritage.
General rules
As a general rule, follow the Google Python Style Guide.
Target Python 3. Do not care about backward compatibility with Python 2.
Black
As of April 2020, we use Black as automated code formatter for all Software Heritage Python code. CI, tox, and other linting tools are configured to fail if code is not formatted as black would.
Note that, as part of this, maximum line length is 88 characters, rather than the default of 79.
Specific rules
As supplement/overrides to the above general rules, follow the additional recommendations below.
Lint
Tests
use
pytest
as test runnerput
tests/
dir down deep in the module hierarchy, near to the code being testedwhenever possible, follow all the guidelines in Stargirl Flowers’ Python testing style guide
Classes
Since we target Python 3, there is no need to inherit from ‘object’ explicitly
Docstrings
docstrings should produce a nice API documentation when run through Sphinx, in particular:
docstrings should be written in reStructuredText
docstrings should use the Napoleon style (Google variant) to document arguments, return values, etc.
see also: a comprehensive style example
see also: Sphinx gotchas