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.
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.
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.
* Add pytest-faulthandler files unchanged
* Adapt imports and tests
* Add code to skip registration of the external `pytest_faulthandler`
to avoid conflicts
Fix#5440
When we configure warnings as errors, users see error messages like this:
def test():
> warnings.warn(pytest.PytestWarning("some warning"))
E _pytest.warning_types.PytestWarning: some warning
This is a problem because suggests the user should use `_pytest.warning_types.PytestWarning` to configure
their warning filters, which is not nice.
This commit changes the message to:
def test():
> warnings.warn(pytest.PytestWarning("some warning"))
E pytest.PytestWarning: some warning
Since then pytest itself adopted the behavior of interrupting
the test session on collection errors, so --sw no longer needs
to handle this.
The --sw behavior seems have been implemented when pytest
would continue execution even if there were collection errors.
As we did not provide an alternative yet, it is better to postpone
the actual removal until we have provided a suitable and stable
alternative.
Related to #4488
Bruno Oliveira
Ran Benita
Ronny Pfannschmidt
Bruno Oliveira
David Röthlisberger
Anthony Sottile
Miro Hrončok
Victor Maryama
Daniel Hahler
Zac Hatfield-Dodds
Kevin J. Foley
Thomas Grainger
Thomas Hisch