fix: raise on any nested container in approx(), not only same-type

[onk3sh]

Closes #10210

What is wrong

approx() refuses to descend into a nested container, and says so clearly — but only when that container happens to be the same type as the one holding it. Both guards test against the parent's type:

• src/_pytest/approx.py:263 — ApproxMapping.__init__: if isinstance(value, type(expected)):
• src/_pytest/approx.py:361 — ApproxSequenceLike.__init__: if isinstance(x, type(expected)):

A dict inside a list, a list inside a dict, a tuple inside a list, a set inside a tuple — none of those match, so they slip past and are compared with == as leaf values. That comparison is exact, so the tolerance is silently ignored:

>>> [{"a": 0.1 + 1e-9}] == approx([{"a": 0.1}])   # inside default tolerance
False
>>> [{"a": 0.1}] == approx([{"a": 0.1}])          # only exact equality passes
True
>>> [[0.1 + 1e-9]] == approx([[0.1]])             # same shape, same-type nesting
TypeError: pytest.approx() does not support nested data structures: [0.1] at index 0

Passing rel= explicitly produces a third behaviour — an error from a lower layer that does not mention nesting at all:

>>> [{"a": 0.11}] == approx([{"a": 0.1}], rel=1e-1)
TypeError: expected value must support abs(...) when relative tolerance is used, got dict

Reported in #10210 in 2022 and still reproducing on main.

The change

Ask whether the value is a container at all, rather than whether it matches the parent's type:

def _is_nested_container(value: object) -> bool:
    return isinstance(value, Collection) and not isinstance(value, str | bytes | bytearray)

str, bytes and bytearray are Collections too, but approx treats them as leaves on purpose and compares them exactly — test_nonnumeric_okay_if_equal covers that, and this PR extends it with bytes cases so the exclusion is pinned by a test rather than by the implementation.

Both existing error messages are untouched, so a nested dict in a list now reports "does not support nested data structures" (the sequence wording, from the container that actually holds it) and a list in a dict reports "does not support nested dictionaries".

#10215 attempted this in 2022 and was closed as stale during the 2026 sprint, with @Zac-HD noting "we'd be delighted to accept a fresh version of this patch". That patch only touched ApproxSequenceLike, so approx({"a": [1.0]}) would still have been silently wrong; this one covers both sides.

Behaviour change worth flagging

A numpy array nested inside a list or dict now raises instead of returning a result. That case was already broken — [np.array([1.0])] == approx([np.array([1.0 + 1e-9])]) returned False before this PR — so this converts a silent wrong answer into a clear error, but it is a visible change for anyone relying on the False. A top-level array is unaffected: ApproxNumpy handles it and does its own nesting.

Tests

testing/python/approx.py:

• extended test_expected_value_type_error with every cross-kind combination — list-of-tuple, list-of-set, list-of-dict, tuple-of-dict, dict-of-list, dict-of-tuple, dict-of-set
• added test_mixed_nested_containers_raise_instead_of_comparing_unequal, which pins the actual bug: values well inside the default tolerance used to compare False instead of raising
• extended test_nonnumeric_okay_if_equal with bytes leaves

Before the change 11 of these fail; after, testing/python/approx.py is 149 passed. Full suite: 4483 passed, 51 skipped, 13 xfailed, 7 xpassed. ruff 0.16.3 check and format clean, mypy 2.3.1 clean on both touched files.

Checklist

• Include new tests or update existing tests when applicable.
• Allow maintainers to push and squash when merging my commits.
• closes #10210 in the PR description and the commit.
• Changelog file changelog/10210.bugfix.rst.
• Added myself to AUTHORS in alphabetical order.
• AI assistance is credited in a Co-authored-by trailer.

[Zac-HD]

Thanks, Onkesh!