Skip to content

Interface fields declare a narrower post_process return type than ip_interface() gives, as two standing mypy [return-value] errors #473

Description

@JarryShaw

Summary

Both interface fields' post_process return the result of
ipaddress.ip_interface(...), which is typed IPv4Interface | IPv6Interface,
against declared return types that admit only one of the two. mypy reports it as
two [return-value] errors, and the declared annotation is a promise the code
does not keep.

Measured

On fa128959e, with the Makefile's own invocation:

pcapkit/corekit/fields/ipaddress.py:216:16: error: Incompatible return value type
    (got "IPv4Interface | IPv6Interface", expected "IPv4Interface")  [return-value]
pcapkit/corekit/fields/ipaddress.py:291:16: error: Incompatible return value type
    (got "IPv4Interface | IPv6Interface", expected "IPv6Interface")  [return-value]

The declarations are at pcapkit/corekit/fields/ipaddress.py:194
(IPv4InterfaceField.post_process -> 'IPv4Interface') and :262
(IPv6InterfaceField.post_process -> 'IPv6Interface').

Why it is worth fixing rather than ignoring

At runtime the value is always the declared type, because the octet count fixes
the version — so this is not a live bug. But it is two of the repository's
standing mypy errors, and it is the kind that hides a real one: a caller reading
the annotation is entitled to assume the narrower type, and the checker cannot
tell the difference between this and a genuine mismatch.

Both sites already validate the version immediately afterwards
(val.version != self.version raising FieldValueError), so the narrowing is
available — it just is not expressed in a way mypy can follow.

Suggested direction

Either construct the concrete class directly rather than going through the
version-dispatching ip_interface() factory, or narrow after the existing
version check in a form mypy accepts. Not a # type: ignore: the annotation
is currently the inaccurate part, and silencing the checker would leave it that
way.

Provenance

Flagged by the agent that produced #470 and verified independently on main
before filing. Pre-existing and unrelated to that PR, which left both errors in
place with only their line numbers shifting.

Activity

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