Skip to content

PYTHON.md

Latest commit

 

History

History
78 lines (52 loc) · 3.04 KB

PYTHON.md

File metadata and controls

78 lines (52 loc) · 3.04 KB

Python practices

Note: mainly this part comes from TezRomacH/python-package-template since it combines good tools I used to know, and some new analysis instruments.

Used libraries

Frameworks

  • FastAPI is good web-framework due to explicit typing requirements, automated documentation, fast backend.

  • Pytest - flexible test framework

Static analysis

  • Mypy - static type checker for python
  • Safety - validates requirements for known security vulnerabilities
  • Bandit - python-code analyzer for common vulnerable code patterns
  • darglint - documentation checker. Validates that documentation corresponds to function implementation by signature

Formatters

  • editorconfig - a tool that allows to describe style rules understandable by many IDEs out-of-box
  • isort - import sorter for reading ease
  • black - good code formatter
  • pyupgrade - tool that replaces deprecated syntax to updated alternatives

VCS integration

  • pre-commit - a tool to simplify management of pre-commit github hooks. Used hooks:
  • gitignore.io - a website that generates gitignore files for popular tools

Build automation

  • Make - handy tool to describe commonly used commands in the project. For example: build, lint, cache-clear

Testing

Unit testing

As mentioned before, the testing is done using pytest framework, since it:

  • provides easy interface for testing
  • has fixture mechanism for state preparation (and dependency resolution between fixtures)
  • is a flexible framework allowing test parametrization and custom plugins

Unit testing practices:

  • Refactor code, so we can test one piece of functionality at a time

  • Tests must be fully independent. In particular:

    • pass regardless the order of execution
    • run on fresh dataset every time

  • Have small readable tests. Usually we can separate 3 parts of a test:

    1. setup: preparation of data. Often common for several tests so can be factored out into fixtures
    2. test: asserting a state
    3. possibly, teardown: if needed -- destruction of data

  • If there are not a lot of tests, we can add running test into pre-commit hooks so that developers do not push a broken code

  • Unit tests should be fast in order not to slow down development. If there are slow test, they should be filtered out and run periodically in a CI job.

  • Keep track of test coverage to verify that new code is at least covered by tests