You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are using pytest as a platform to execute qualification tests and have some documents generated from the output automatically. We therefore have a suite of tests with approx and/or numpy comparisons with tolerances.
This means we need to assert/log the differences between numpy arrays, which might be wrapped by pytest.approx.
Describe the solution you'd like
I would like to check whether the value compared is a value wrapped with approx and output the values in a specific way if it is.
I can use the ApproxBase type in _pytest.python_api in a isintance() check, and that works, but I would prefer if we didn't need to use the _pytest package as that is considered private.
Yes, this is marked as a TODO in #7469. It is the return type of pytest.approx so I think it makes sense to expose it in some form.
Some prerequisites for this (IMO):
Add _ispytest protection to the ctor to make it clear it is not meant to be instantiated. Alternatively, make it an ABC (probably a better idea, marking __repr__ and _yield_comparisons as @abstractmethod).
Improve the docstring for public exposure. Currently says "Provide shared utilities for making approximate comparisons between numbers or sequences of numbers". It would need to say something more like "The return value of pytest.approx()." and maybe a few words about its comparison behavior, or just say "see there for details".
Mark the attributes Final, I reckon none of them need to be mutable.
Decide which of the attributes should be public, and add _ prefix to the others:
expected
abs
rel
nan_ok
These are just the stable parameters of pytest.approx() so I think it's fine to expose and document them.
I think we should think of a better name, maybe just Approx. The Base is an implementation detail, meaningless for a user of pytest.approx.
Finally, exposing it means rexporting from src/pytest/__init__.py and adding to the API Reference. Patches welcome :)
Activity
RonnyPfannschmidt commentedon Feb 5, 2026
@bluetech i sense a need to bikeshedd what to epxpose for typing purposes
bluetech commentedon Jun 11, 2026
Yes, this is marked as a TODO in #7469. It is the return type of
pytest.approxso I think it makes sense to expose it in some form.Some prerequisites for this (IMO):
Add
_ispytestprotection to the ctor to make it clear it is not meant to be instantiated. Alternatively, make it an ABC (probably a better idea, marking__repr__and_yield_comparisonsas@abstractmethod).Improve the docstring for public exposure. Currently says "Provide shared utilities for making approximate comparisons between numbers or sequences of numbers". It would need to say something more like "The return value of pytest.approx()." and maybe a few words about its comparison behavior, or just say "see there for details".
Mark the attributes
Final, I reckon none of them need to be mutable.Decide which of the attributes should be public, and add
_prefix to the others:expectedabsrelnan_okThese are just the stable parameters of
pytest.approx()so I think it's fine to expose and document them.I think we should think of a better name, maybe just
Approx. TheBaseis an implementation detail, meaningless for a user ofpytest.approx.Finally, exposing it means rexporting from
src/pytest/__init__.pyand adding to the API Reference. Patches welcome :)approx: expose `pytest.Approx` as the return type of `pytest.approx`
approx: expose `pytest.Approx` as the return type of `pytest.approx`