Fix NUMBER and ELLIPSIS doctest interaction

[Yoruxyv]

Closes #13327

Summary

Fixes the interaction between the NUMBER and ELLIPSIS doctest options when an ellipsized region contains additional numeric values.

Previously, NUMBER collected numeric tokens from the entire expected and actual output and paired them positionally. This breaks with ELLIPSIS, which can hide arbitrary output including additional numbers.

This change keeps the existing NUMBER-only path unchanged and adds an ellipsis-aware fallback that aligns the visible, non-ellipsis portions of the expected output before applying the existing NUMBER precision logic.

It also preserves NORMALIZE_WHITESPACE behavior by normalizing whitespace before the ellipsis-aware alignment.

Reproduction

The original issue can be reproduced using the reporter's repository:

git clone https://github.com/wade-cheng/pytest-doctest-bug.git
cd pytest-doctest-bug

python -m pytest -v --doctest-modules working.py
python -m pytest -v --doctest-modules failing.py

On unmodified pytest main, working.py passes while failing.py fails.

With this change, both pass.

Tests

Added coverage for:

• NUMBER before and after an ellipsized region containing additional numbers
• multiple ellipsized regions
• a non-matching visible number, to ensure the fallback does not introduce false positives
• NUMBER + ELLIPSIS + NORMALIZE_WHITESPACE

Validation performed with:

python -m pytest testing/test_doctest.py -k "number" -vv
python -m pytest testing/test_doctest.py -vv
python -m tox -e py313 -- testing/test_doctest.py
python -m tox -e linting

Results:

NUMBER-focused tests: 24 passed, 1 xfailed
testing/test_doctest.py: 165 passed, 1 xfailed
tox py313: 165 passed, 1 xfailed
linting: passed

Why not just remove the numeric-count check?

The existing implementation assumes that the expected and actual output contain the same number of numeric tokens. Simply removing the numeric-count check is not sufficient: the current pairing uses zip(..., strict=True), and relaxing it would still leave numeric tokens paired by their global position.

For example:

Expected:
... final=3.0

Actual:
hidden=2.0 final=3.0001

A positional pairing would associate the expected 3.0 with the hidden 2.0, even though that value belongs to the ellipsized region.

The fallback therefore aligns the visible portions first and only applies NUMBER matching to numbers that belong to those portions.

[MateehUllah]

The ellipsis-aware suffix path can raise ValueError for an ordinary non-match instead of returning False. For example, with want='prefix ... value=1.0' and got='prefix', position is negative, but match_numbers(position, last_numbers) is called before the position < start and endswith guards. That produces an empty matched_got_numbers slice, and zip(..., strict=True) raises because last_numbers contains one item.

A doctest mismatch should remain a failed comparison, not escape from the output checker. Please perform the suffix position/shape checks before calling match_numbers and add a regression with a missing or shortened trailing numeric chunk.

[Yoruxyv]

Thank you so much for catching this @MateehUllah. I had missed that edge case, and your example made the failure mode very clear. I’ve updated the suffix handling so the position/shape checks happen before numeric matching and added a regression test for the shortened trailing chunk. Really appreciate the review!

[Yoruxyv]

While rechecking the ellipsis-aware path against stdlib doctest.OutputChecker semantics, I found two additional preprocessing cases that needed to be preserved: <BLANKLINE> handling and ASCII/Unicode canonicalization before ellipsis matching.
I added focused regression coverage for both, including preservation of DONT_ACCEPT_BLANKLINE, and updated the fallback to apply the same relevant pre-ellipsis canonicalization before performing the NUMBER-aware alignment. The final comparison is still delegated to stdlib's OutputChecker.