Skip to content

refactor(corekit): take the stdlib version detections (get_annotations, UnionType, dict reversal) from compat behind version gates #1709

Closed

Description

@JarryShaw

Describe the bug
#1702 (for #1692) detects inspect.get_annotations with _get_annotations = getattr(inspect, 'get_annotations', None), and falls back to a class's own __dict__ below Python 3.10, inside pcapkit/corekit/infoclass.py. The owner prefers version detection and its fallback to live in pcapkit/utilities/compat.py as a re-export, as was asked on #1701.

Expected behavior
compat.py re-exports get_annotations, selected by a sys.version_info gate rather than a getattr/hasattr probe (the owner's preference on #1703): inspect.get_annotations on 3.10 and later, and a reader of the class's own __dict__['__annotations__'] below. infoclass.py imports it from there. Behaviour is unchanged on every version.

The same file also probes hasattr(dict, '__reversed__') at pcapkit/corekit/infoclass.py:902 and :993 (dict reversal is Python 3.8+). Those become sys.version_info gates too, found by the #1703 round-2 worker.

A grep of pcapkit/ at 375d37ae5 finds two more probes of the same kind, both in scope here:

  • pcapkit/corekit/infoclass.py:1066: _UNION_TYPE = getattr(types, 'UnionType', None) (3.10+).
  • pcapkit/protocols/protocol.py:2174: a second getattr(inspect, 'get_annotations', None), which can use the same compat get_annotations.

Blocked until #1701 merges, since both edit compat.py.

Activity

  1. added
    refactorRestructuring for its own sake — neither a fix nor a new capability (refactor: prefix)
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    on Oct 14, 2026
  2. moved this to Blocked in PyPCAPKiton Oct 14, 2026
  3. changed the title [-]refactor(corekit): take inspect.get_annotations' detection and fallback from compat[/-] [+]refactor(corekit): take the stdlib version detections (get_annotations, UnionType, dict reversal) from compat behind version gates[/+] on Oct 14, 2026
  4. JarryShaw commented on Oct 14, 2026

    @JarryShaw
    OwnerAuthor

    #1701 has merged, but #1707 also edits pcapkit/utilities/compat.py and is being rebased onto it now. This stays blocked until #1707 merges, to avoid a third conflict there.

  5. added
    wipWork in flight - a covering PR is open or an agent is actively on it
    and removed
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    on Oct 14, 2026
  6. JarryShaw commented on Oct 14, 2026

    @JarryShaw
    OwnerAuthor

    #1707 has merged, so compat.py is free. A worker is on it, using sys.version_info gates in compat.py per the ruling on #1703.

  7. moved this from Blocked to WIP in PyPCAPKiton Oct 14, 2026
  8. removed
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Oct 14, 2026
  9. added this to the PyPCAPKit v1.5 milestone on Oct 26, 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

    refactorRestructuring for its own sake — neither a fix nor a new capability (refactor: prefix)

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions