Difference between revisions of "Python style guide"

From Software Heritage Wiki
Jump to: navigation, search
(Specific rules: drop single quote mention, as black uses double quotes)
(Lint)
(One intermediate revision by the same user not shown)
Line 19: Line 19:
 
=== Lint ===
 
=== Lint ===
  
* Make sure your code is [https://flake8.readthedocs.org/ flake8] clean.
+
* Make sure your code is [https://flake8.readthedocs.org/ flake8] and [https://black.readthedocs.io/ Black] clean.
  
 
=== Tests ===
 
=== Tests ===
  
* use <tt>unittest</tt> for assertions, <tt>nosetests3</tt> as test runner
+
* use <tt>pytest</tt> as test runner
 
* put <tt>tests/</tt> dir down deep in the module hierarchy, near to the code being tested
 
* put <tt>tests/</tt> dir down deep in the module hierarchy, near to the code being tested
 
* naming conventions:
 
* naming conventions:

Revision as of 15:38, 8 April 2020

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 runner
  • put tests/ dir down deep in the module hierarchy, near to the code being tested
  • naming conventions:
    • tests/test_mymodule.py
    • class TestMyEntity(unittest.TestCase)
    • def behavior(self):
      • do not prepend test_ to all test methods; use nose's @istest decorator instead

Classes

Docstrings

See also