Extend sphinx to include icontracts.
Sphinx-icontract extends Sphinx to include icontracts of classes and functions in the documentation.
Sphinx-icontract is based on the sphinx.ext.autodoc module. You need to specify both modules in extensions of your Sphinx configuration file (conf.py).
Here is an example excerpt:
# Add any Sphinx extension module names here, as strings. They can be # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom # ones. extensions = [ 'sphinx.ext.autodoc', 'sphinx_icontract' ]
Sphinx-icontract tries to infer the implications from the conditions and render them as implication (... ⇒ ...). We implemented a rule-based matching that covers most of the practical use cases:
- not A or B is translated to A ⇒ B.
- Expressions are negated, so x < y or B is translated to x >= y ⇒ B. More general expressions are negated with not: from x.y() or B to not x.y() ⇒ B.
- If-Expressions are translated from B if A else True to A ⇒ B.
We found implications in form of if-expressions to be confusing when read in source code and encourage programmers to use disjunction form instead.
If you specify custom errors in the contract, sphinx-icontract will try to include the error in the documentation.
The error type will be inferred from the contract’s error argument. If the error message is given as a string literal and there is no contract description, the error message will be used to describe the contract so that you do not have to specify the description twice (once in the description of the contract and once in the error message).
@icontract.require( lambda x: x > 0, error=lambda: ValueError("x positive")) def some_func(x: int) -> None: pass
will be documented as:
:requires: * :code:`x > 0` (x positive; raise :py:class:`ValueError`)
If both the description and the error message are given, only the description will be included:
@icontract.require( lambda x: x > 0, description="x must be positive", error=lambda: ValueError("x positive")) def some_func(x: int) -> None: pass
will be rendered as:
:requires: * :code:`x > 0` (x must be positive; raise :py:class:`ValueError`)
Be careful when you write contracts with custom errors which are included in the documentation. This might lead the caller to (ab)use the contracts as a control flow mechanism.
In that case, the user will expect that the contract is always enabled and not only during debug or test. (For example, whenever you run python interpreter with -O or -OO, __debug__ will be False. If you passed __debug__ to your contract’s enabled argument, the contract will not be verified in -O mode.)
- Install sphinx-icontract with pip:
pip3 install sphinx-icontract
- Check out the repository.
- In the repository root, create the virtual environment:
python3 -m venv venv3
- Activate the virtual environment:
- Install the development dependencies:
pip3 install -e .[dev]
We use tox for testing and packaging the distribution:
We provide a set of pre-commit checks that lint and check code for formatting.
Namely, we use:
- yapf to check the formatting.
- The style of the docstrings is checked with pydocstyle.
- Static type analysis is performed with mypy.
- Various linter checks are done with pylint.
- Contracts are linted with pyicontract-lint.
- Doctests are executed using the Python doctest module.
Run the pre-commit checks locally from an activated virtual environment with development dependencies:
- The pre-commit script can also automatically format the code:
We follow Semantic Versioning. The version X.Y.Z indicates:
- X is the major version (backward-incompatible),
- Y is the minor version (backward-compatible), and
- Z is the patch version (backward-compatible bug fix).
Release history Release notifications | RSS feed
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
|Filename, size||File type||Python version||Upload date||Hashes|
|Filename, size sphinx-icontract-2.0.1.tar.gz (11.2 kB)||File type Source||Python version None||Upload date||Hashes View|