Skip to content

fix(mh): two kept get overrides advertise the base default argument and reject it with TypeError #935

Closed

Description

@JarryShaw

The two kept @staticmethod get overrides in pcapkit/protocols/internet/mh.py — FastBindingAcknowledgmentStatus and IPv6AddressPrefixCode — now advertise the base's two-argument get(key, default) through inheritance from EnumLookup, and reject it:

FastBindingAcknowledgmentStatus.get('bogus', 'Handover_Accepted')
# TypeError: get() takes 1 positional argument but 2 were given

LMAAddressCode.get('bogus', 'default')      # a pure re-parent in the same module
# EnumKeyError: 'bogus' is not a valid LMAAddressCode   <- honours default

So two of the seven classes #930 re-parented behave differently from the other five on the same call, and the difference is a TypeError rather than a documented refusal. Before the re-parent nothing advertised a default on these classes at all, so this is a gap the re-parenting introduced — not a pre-existing one.

It is exactly what the # type: ignore[override] # pylint: disable=arguments-differ suppression hides. Verified that the suppression is load-bearing: stripping it and re-running mypy yields

mh.py:645:5 error: Signature of "get" incompatible with supertype "EnumLookup"  [override]
mh.py:782:5 error: Signature of "get" incompatible with supertype "EnumLookup"  [override]

and --warn-unused-ignores reports no unused ignore at either line.

Not a defect in #932, which is why this is its own issue rather than a change there: the behaviour predates that PR's final amendment, it is disclosed verbatim in both docstrings ("no cls, no default … silenced rather than resolved by widening the signature"), and it is orthogonal to the quiet=True change #933 asked for. Filing it so the disclosure does not become the permanent answer.

Three ways out, and the choice is yours:

  1. Widen both signatures to accept default and delegate, which removes the suppression and makes all seven behave alike. Most invasive, most correct.
  2. Keep the signatures and make the refusal explicit — accept default and raise a clear in-library error saying it is unsupported, so callers get a diagnosis instead of a TypeError.
  3. Leave it, and treat the docstring disclosure plus the suppression as the settled answer.

Surfaced by the Opus cross-review of #932 and verified independently.

Activity

  1. added
    bugIssues reporting a defect (set by the bug report template; a default, not an assessment)
    designA design or decision issue: a pattern being decided rather than a defect or a request
    needs: decisionWaiting on the maintainer to decide — not blocked by other work
    on Sep 29, 2026
  2. JarryShaw commented on Sep 29, 2026

    @JarryShaw
    OwnerAuthor

    I lean on 1.

  3. JarryShaw commented on Sep 30, 2026

    @JarryShaw
    OwnerAuthor

    Ruling recorded, verbatim:

    I lean on 1.

    So option 1: widen both get signatures in pcapkit/protocols/internet/mh.py — FastBindingAcknowledgmentStatus and IPv6AddressPrefixCode — to accept default and delegate, making all seven re-parented classes behave alike on get(key, default) and removing the two # type: ignore[override] # pylint: disable=arguments-differ suppressions rather than keeping them.

    That is the most correct of the three and it deletes the defect at its root: the TypeError: get() takes 1 positional argument but 2 were given goes away, and the base's contract stops being advertised-but-unhonoured. Verified that the suppressions are load-bearing today — stripping them without widening yields real errors at mh.py:645:5 and :782:5, Signature of "get" incompatible with supertype "EnumLookup" [override] — so widening is precisely what lets them go.

    Blocked on #932, on file contention. mh.py is one of that PR's eleven files, and #932 has just gone back to review: needs-changes over the ESPStatus stdlib-IntEnum finding, so it will be amended again. Two agents editing mh.py at once lose each other's work silently, which is why this waits rather than racing it.

    One scoping question, since the two changes now overlap. This fix removes the two suppressions that #932 adds, in the same two functions. Landing #932 with them and then deleting them in a follow-up is churn, and the follow-up would conflict with whatever #932 amends next. Would you rather I fold this into #932 — it is already being amended for the ESPStatus finding, and its commit message can carry both issues — or keep it as its own PR after #932 merges? I lean on folding it in, since it touches the same two functions and #932 is not merged. Say if you would rather keep the histories separate.

    needs: decision removed; blocked applied.

  4. added
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    wipWork in flight - a covering PR is open or an agent is actively on it
    and removed
    needs: decisionWaiting on the maintainer to decide — not blocked by other work
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    on Sep 30, 2026
  5. removed
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Sep 30, 2026
  6. added this to the 1.5 milestone on Oct 6, 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)designA design or decision issue: a pattern being decided rather than a defect or a request

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions