pytest.approx fails with TypeError: unsupported operand type(s) for -: 'float' and 'NoneType'

[milanwiedemann]

When using approx to test float and one of the objects in the assert statement contain None I see the following TypeError:

TypeError: unsupported operand type(s) for -: 'float' and 'NoneType'.

Minimal example

Test

import pytest


# Expecting assertion error with differing item
# Instead I see "TypeError: unsupported operand type(s) for -: 'float' and 'NoneType'."
def test_pytest_none_approx():
    actual_result = {"a": 1.2}
    expected_result = {"a": None}
    approx_expected_result = pytest.approx(expected_result)
    assert approx_expected_result == actual_result

Output

E       AssertionError: assert approx({'a': 1.2 ± 1.2e-06}) == {'a': None}
E         (pytest_assertion plugin: representation of details failed: /Users/milanwiedemann/.pyenv/versions/3.10.4/lib/python3.10/site-packages/_pytest/python_api.py:270: TypeError: unsupported operand type(s) for -: 'float' and 'NoneType'.
E          Probably an object has a faulty __repr__.)

pip list

Package        Version
-------------- -------
attrs          22.2.0
exceptiongroup 1.1.0
iniconfig      2.0.0
packaging      23.0
pip            22.0.4
pluggy         1.0.0
pytest         7.2.1
setuptools     58.1.0
tomli          2.0.1

Cersions of OS and pytest

• macOS 12.6.3
• python 3.10.4
• pytest 7.2.1

[RonnyPfannschmidt]

We should probably error earlier, none is not approx-able

It seems to be a mistake to let approx take dict for convenience

[kenny-y-dev]

It appears that None is currently functional when passing it directly to approx, but not when passed as part of a dictionary (which gets processed by the ApproxMapping class, and a subtraction operation on the dict value is throwing the error).

I do agree that None shouldn't be approx-able based on what the function should be doing, though an early error on None may break existing tests, so should ApproxMapping instead be adjusted to better handle None? The documentation does include dictionaries with None values, and keeping the dict functionality may be helpful when dealing with multiple values from the same function run in a way that parameterize wouldn't cover.

I'm open to work on any of the above options, let me know the preferred direction!

[nicoddemus]

so should ApproxMapping instead be adjusted to better handle None?

I vote for that one; deprecating None would be a whole can of worms, but handling None seems to be the way to fix this, given the current failure is not acceptable.