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.
Summary
Both interface fields'
post_processreturn the result ofipaddress.ip_interface(...), which is typedIPv4Interface | 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 codedoes not keep.
Measured
On
fa128959e, with the Makefile's own invocation: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.versionraisingFieldValueError), so the narrowing isavailable — 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 existingversion check in a form mypy accepts. Not a
# type: ignore: the annotationis 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
mainbefore filing. Pre-existing and unrelated to that PR, which left both errors in
place with only their line numbers shifting.