test: reword PcapngUnescapedKeyTests' claims that #784 falsified

[JarryShaw]

Please follow the guide below

• You will be asked some questions, please read them carefully and answer honestly

• Put an x into all the boxes [ ] relevant to your pull request (like that [x])

• Use Preview tab to see how your pull request will actually look like

• Searched for similar pull requests

• Followed the coding style (make pylint, make mypy, make isort)

• make test passes, and a test case covers the change

• Added a changelog entry under docs/source/changelog/ and regenerated CHANGELOG.md, if the change is user-visible — N/A — changelog centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

What is the purpose of your pull request?

Tick the commit type your subject line carries.

• fix — corrects a defect
• feat — adds a feature
• perf — changes performance, not behaviour
• refactor — changes neither behaviour nor performance
• test — tests only
• docs — documentation only
• ci — workflows or build tooling
• chore — anything else

---

Description of your pull request and other information

Measured on ef859f776: json.load now fails at line 1019, column 12 (not the docstring's claimed 915); the plist report of the same fixture now parses as well-formed XML, thanks to #784's escape_key fix in pcapkit/dumpkit/common.py:250.

Confirmed the pre-#784 plist failure really was line 1517 of 1958 (measured in a scratch worktree at 0419c1c97), matching #785's own measurement — so the docstring's 1376 had already drifted before #784 landed, not because of it.

Reworded the class and method docstrings in PcapngUnescapedKeyTests to name only the surviving json quoting defect (still open upstream as JarryShaw/DictDumper#121 -- the mapping-key issue; #125 is the separate plist string-value one), dropped the now-false plist claim, and flagged the json line number as fixture-dependent rather than a fixed fact — a stale instance of exactly that kind of number is what #785 was filed over. The @unittest.skip reason itself made no false claim and needed no change.

Test still skips, unchanged: 6 passed, 1 skipped, 25 subtests passed in tests/integration/test_pcapng_end_to_end.py.

Closes #785

[JarryShaw]

Cross-review at 0033d5394 (fable, a different model from the author): NEEDS CHANGES — one wrong issue number, and one drifted line number in a PR whose whole purpose is removing drifted line numbers.

1. The upstream citation is the wrong issue, and the error is mine. Verified directly:

DictDumper#121 [OPEN] JSON and PLIST dumpers write mapping keys into the document unescaped
DictDumper#125 [OPEN] PLIST writer does not escape <, > or & in string values

The surviving json defect is the key one, so it is #121, not #125. #790 inherited this from my own Closes #772 paragraph on #784, which said the _encode_value-on-keys change "stays tracked at JarryShaw/DictDumper#125" — wrong when I wrote it. It is doubly confusing here, because the docstring sends a reader chasing the json defect to an issue about the plist half it has just said was fixed.

The four pre-existing #125 references on main are correct and stay — pcapkit/dumpkit/common.py:240 and the three in tests/dumpkit/ all describe the plist value/markup half, which is genuinely #125.

2. A stale line number survived. Line 169 of the same docstring cites pcapkit/protocols/schema/misc/pcapng.py:1450 for the bytes.fromhex(random) keying. It is at :1982 on main, and already was at 0419c1c97.

$ git show origin/main:pcapkit/protocols/schema/misc/pcapng.py | grep -n "bytes.fromhex(random)"
1982:            entries[label_enum].add(bytes.fromhex(random),

3. A smaller wording point, also measured. Line 189 says #784 fixed the plist half "by teaching escape_key ... to XML-escape mapping keys", which implies the helper predated #784. It did not — escape_key has zero occurrences at 0419c1c97; #784 introduced it.

Also worth folding in: #785 asked that a retained number be justified by a measurement at the commit that records it. The PR body names ef859f776; the docstring only says "what this run measured". Putting the sha in the docstring closes that properly.

The review confirmed everything else, including all three measurements, the untouched skip reason, and that no other copy of the false claims survives. Routing the fix.

[JarryShaw]

Revised to a3900621e, all four points applied — plus the same mis-citation in the commit message and the PR body, which I had missed.

The line-number sweep you asked for. I checked every citation in that class's docstrings by grepping for the cited construct rather than trusting the number. Only one was wrong:

pcapng.py:1450  -> bytes.fromhex(random) is at :1982      WRONG, fixed
dictdumper/json.py:224 -> keys = '{cmma}\n{tabs}"{item}": '.format(...)   correct
dumpkit/common.py:250  -> def escape_key(key: 'Any') -> 'Any':            correct

So 1450 was the only survivor, and it had already drifted at 0419c1c97 — independently of #784.

Also done: #125 → #121 in the docstring, the commit message and the PR body; "teaching escape_key" → "adding an escape_key helper", since it has zero occurrences at 0419c1c97; and the retained number is now anchored — "Measured on this fixture at ef859f776" — which is what #785's own condition asked for.

tests/integration/test_pcapng_end_to_end.py: 7 tests, OK (skipped=1). The skip reason string is untouched — no +/- line in the diff mentions it.

One process note worth recording rather than hiding: my first run of this module came back FAILED (errors=12). That was not a defect — a fresh worktree carries only the two tracked captures, and PcapngByteOrderTests needs the generated dhcp_big_endian.pcapng and dhcp_little_endian.pcapng. Copying the fixtures in gave the clean result above. Reporting it because a red count that turns out to be a missing fixture is exactly the kind of thing that gets quietly dropped.

Re-reviewing at the new head before I set a verdict.

[JarryShaw]

Delta re-check at a3900621e (fable, resumed so it re-checked its own findings): GOOD TO GO, all three fixed. It re-derived rather than accepted:

• Scheduled weekly dependency update for week 43 #121 now in the docstring, commit message and PR body; git grep DictDumper#125 returns exactly the four pre-existing refs (dumpkit/common.py:240, tests/dumpkit/test_common_unit.py:230, test_plist_escaping_regression.py:13 and :114), untouched and correct there.
• :1982 confirmed by printing line 1982 itself, and it re-ran the whole citation sweep over the file independently: lines 162, 169, 173, 190 are the only .py:N citations and all four now check out. No missed citation.
• The anchored number verified against its own first-pass measurement on a proven ef859f776 tree: Expecting ':' delimiter: line 1019 column 12 (char 51357).

It caught one residual I had missed, which I have now fixed at 91bde048b (tree byte-identical, message only): the commit message's opening paragraph still read "#784 taught ... escape_key to XML-escape mapping keys" — the same pre-existence implication I had removed from the docstring, left standing in permanent history. escape_key has zero occurrences at 0419c1c97. Now reads "added an escape_key helper".

And it corrected my fixture diagnosis, in my favour. A truly bare worktree gives 13 errors, not the 12 I reported — the difference is the test.pcapng error, which my worktree did not hit because I had copied that one capture in for an earlier measurement. All 13 are the harness's own FileNotFoundError: sample capture '...' not found; 4×dhcp_big_endian, 3×dhcp_little_endian, 3×many_interfaces, 2×profile, 1×test.pcapng. So the diagnosis held and only my count was an artefact of a partly-populated tree. Worth stating, since "12 vs 13" is exactly the kind of number this PR exists to stop people inheriting.

Setting review: good-to-go. Unpublished and unmerged — yours to take. Closes #785.