Skip to content

docs(stats): update get_stats() example to current output (worker keys + counts) - #622

Closed
pacocartones wants to merge 1 commit into
qlustered:devfrom
pacocartones:doc/stats-get-stats-worker-keys
Closed

pacocartones wants to merge 1 commit into
qlustered:devfrom
pacocartones:doc/stats-get-stats-worker-keys

Conversation

@pacocartones

Copy link
Copy Markdown

Fix the get_stats() example in the Stats docs

The example output under "Get Stats" in docstrings/stats.rst is out of date. Since
the multiprocessing support landed in 9.1.0, get_stats() also returns four
aggregated worker counters that are always present (zeroed on a serial run):

  • WORKER DIFF COUNT
  • WORKER PASSES COUNT
  • WORKER DISTANCE CACHE HIT COUNT
  • WORKER BATCH COUNT

The documented example still shows the pre-9.1.0 dict, so it neither lists those keys
nor matches the current counter values. Running the example exactly as written now
gives:

>>> pprint(diff.get_stats())
{'DIFF COUNT': 54,
 'DISTANCE CACHE HIT COUNT': 9,
 'MAX DIFF LIMIT REACHED': False,
 'MAX PASS LIMIT REACHED': False,
 'PASSES COUNT': 7,
 'WORKER BATCH COUNT': 0,
 'WORKER DIFF COUNT': 0,
 'WORKER DISTANCE CACHE HIT COUNT': 0,
 'WORKER PASSES COUNT': 0}

This updates the example to that output. Docs-only change; the WORKER * keys being
present in serial mode is the intended behaviour and is already covered by
tests/test_multiprocessing.py.

(docs/stats.rst is a symlink to deepdiff/docstrings/stats.rst, so the single edit
covers both.)

The get_stats() example in stats.rst predates the multiprocessing support
added in 9.1.0: it still shows DIFF COUNT 37 / DISTANCE CACHE HIT COUNT 0 and
omits the four WORKER * keys that get_stats() now always returns (a test,
test_serial_run_exposes_worker_keys_zeroed, enforces their presence). The .rst
files are not run as doctests, so the drift went unnoticed. This updates the
example to the exact current output (run against dev).
@pacocartones

Copy link
Copy Markdown
Author

Closing this to keep your queue clean; the change still merges cleanly into 59acdd9cbb50 if it's ever useful. Thanks for your time.

@seperman

seperman commented Oct 8, 2026

Copy link
Copy Markdown
Member

Thanks @pacocartones
I need to start reviewing the PRs that are piling up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants