Skip to content

fix(dumpkit): dictdumper 0.8.5 fixed the defects common.py works around; now double-escaping #2442

Closed

Description

@JarryShaw

Describe the bug

dictdumper just released 0.8.5, fixing two defects PyPCAPKit's pcapkit/dumpkit/common.py has been working around since before the fix existed: string/key escaping (DictDumper#121/#125, tracked here as #772) and the PLIST <date> format (DictDumper#122, tracked here as #1448). pyproject.toml pins dictdumper~=0.8.0, which resolves to 0.8.5, so every fresh CI install now picks up the fix underneath PyPCAPKit's own now-redundant workaround — producing double-escaped output. Confirmed on PR #2441 (unrelated to that PR's own changes): tests/dumpkit/test_dumper_roundtrip_unit.py fails with e.g. 'a&lt;b' where 'a<b' is expected, after plistlib.loads() — the PLIST workaround's own xml.sax.saxutils.escape() now runs on text dictdumper has already escaped.

To Reproduce

Any current CI run installs dictdumper==0.8.5; tests/dumpkit/test_dumper_roundtrip_unit.py and test_fallback_cycle_unit.py fail on every Python version.

Expected behavior

pcapkit/dumpkit/common.py's escape_strings/escape_keys/escape_json_keys workaround (for #772/DictDumper#125 and DictDumper#1152, both fixed by DictDumper#123) and plist_dates (for #1448, fixed by DictDumper#124) should be removed now that the upstream fix is live — not doubled up. keep_none (#1257) and tree_numbers (#1266) address unrelated defects DictDumper 0.8.5 did not touch and must stay.

Additional context

Bump the dictdumper constraint in pyproject.toml to >=0.8.5 to make the real requirement explicit rather than relying on ~=0.8.0 happening to resolve there. Test fixtures in tests/dumpkit/ that currently expect the old unescaped/non-fixed output need updating to expect the real (correct) dictdumper 0.8.5 behavior.

Activity

  1. added
    bugIssues reporting a defect (set by the bug report template; a default, not an assessment)
    on Oct 30, 2026
  2. added
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Oct 30, 2026
  3. moved this to Pending in PyPCAPKiton Oct 30, 2026
  4. added this to the PyPCAPKit v1.5 milestone on Oct 30, 2026
  5. moved this from Pending to WIP in PyPCAPKiton Oct 30, 2026
  6. added 2 commits that reference this issue on Oct 30, 2026
    1cca7c8
    7e61bfb
  7. added a commit that references this issue on Oct 30, 2026
  8. removed
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Oct 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugIssues reporting a defect (set by the bug report template; a default, not an assessment)

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions