This makes testing/ actually pick up the pytest imports -- otherwise
they are opaque and we don't actually test the types.
A single run is also a bit faster and simpler. The original reason why
we split it is no longer relevant (we fixed the problems).
This function is not called anywhere directly, and cannot be called by
the dynamic `repr_<type>()` dispatch mechanism because unicode is no
longer a type in Python 3.
This reverts commit dfe54cd82f.
The idea in the commit was to simplify the code by removing the check
and instead letting it TypeError which has the same effect.
However this type error is caught by mypy, and rather than ignoring the
error we think it's better and clearer to go back to the previous
explicit check.
These doctests were expected to fail, but they were failing because of a
silly bug (I forgot to replace "{expression}" with the actual expression
to be tested), not because of the thing they were meant to be testing.
Then I had to fix one of the testcases because it was actually matching:
>>> 3.0 #doctest: +NUMBER
2.99
The doctest is saying that the actual output should match to 2 decimal
places, i.e. within 0.01 -- which it is, so it passes. I changed the
expected output to 2.98 and now it doesn't match (as we expect).
Add a very lax mypy configuration, add it to tox -e linting, and
fix/ignore the few errors that come up. The idea is to get it running
before diving in too much.
This enables:
- Progressively adding type annotations and enabling more strict
options, which will improve the codebase (IMO).
- Annotating the public API in-line, and eventually exposing it to
library users who use type checkers (with a py.typed file).
Though, none of this is done yet.
Refs https://github.com/pytest-dev/pytest/issues/3342.
* Move the parts about "how to configure it" (pytest.ini vs. inline
comment) together.
* Move `--doctest-continue-on-failure` into its own sub-heading, as it
isn't related to the doctest optionflags.
When enabled, floating-point numbers only need to match as far as the
precision you have written in the expected doctest output. This avoids
false positives caused by limited floating-point precision, like this:
Expected:
0.233
Got:
0.23300000000000001
This is inspired by Sébastien Boisgérault's [numtest] but the
implementation is a bit different:
* This implementation edits the literals that are in the "got"
string (the actual output from the expression being tested), and then
proceeds to compare the strings literally. This is similar to pytest's
existing ALLOW_UNICODE and ALLOW_BYTES implementation.
* This implementation only compares floats against floats, not ints
against floats. That is, the following doctest will fail with pytest
whereas it would pass with numtest:
>>> math.py # doctest: +NUMBER
3
This behaviour should be less surprising (less false negatives) when
you enable NUMBER globally in pytest.ini.
Advantages of this implementation compared to numtest:
* Doesn't require `import numtest` at the top level of the file.
* Works with pytest (if you try to use pytest & numtest together, pytest
raises "TypeError: unbound method check_output() must be called with
NumTestOutputChecker instance as first argument (got
LiteralsOutputChecker instance instead)").
* Works with Python 3.
[numtest]: https://github.com/boisgera/numtest
These attributes can be used to access the unchanged arguments passed
to pytest.main().
The intention is to use these attributes to initialize workers in
the same manner as the master node is initialized in pytest-xdist.
Ran Benita
Bruno Oliveira
Ronny Pfannschmidt
David Röthlisberger
Anthony Sottile
Bruno Oliveira