Use Python 3
Use Python 3.
Read PEP 20
python -m this, every now and again.
If there’s anything to emphasize here that directly influences day-to-day writing, they are:
- Explicit is better than implicit
- Flat is better than nested
- Sparse is better than dense
- If the implementation is hard to explain, it’s a bad idea
PEP257 specifies base Docstring conventions, however format is not-included. People usually choose between reST, Google style, and Numpydoc, the latter two being the most popular.
Write Examples and “Test” Them
doctest runs examples formatted like so in your Docstrings:
> factorial(5) 120
If the output of the
> line equals to the following line, your example passes. It tests every line that has an expected literal result.
This makes sure you write up to date examples, in case your API changes.
pycodestyle, and McCabe script in one. However,
flake8 does not catch some import and object issues like
pylint can be slow.
So consider this:
- For real-time linting, use
- For on-save linting, use
Additionally, I like using
pydocstyle for consistent looking Docstrings.
Is your project OSS? Do your teammates hate linters?
Use pre-commit hooks.
.pylintrc, enforce the use of
pre-commit hooks for
Package your Project
Learn how to use
setup.py, and keep your abstract dependencies under its
Required reading: setup.py vs requirements.txt
Use Pipfiles, forget requirements.txt, forget virtualenvs
pipenv and never look back. This will manage your venvs and your concrete dependencies.
Almost every time, you will have the following in your Pipfile:
[packages] "-e ." = "*"
Bonus reading: pipenv#209
pytest, tests folder in project root, avoid
__init__.py files in your tests folder.
This ensures your tests can be run against an installed version of your package, i.e.
Strive for 100% Test Coverage,
pipenv install pytest-cov --dev.
Pick out Best Practices you like
But not everything is up for discussion, don’t be a heathen and choose tabs over spaces.