IPv6_Route.__post_init__ documents src_ip/dst_ip, which exist only in an @overload stub

[JarryShaw]

Found by the prose-against-code strand of the sweep and deliberately excluded from #490/PR #501, because it is not the copy-paste phantom the other six items there were. Re-measured on main at d2d9bb80c.

The mismatch

IPv6_Route.__post_init__ documents two parameters that the runtime signature does not have:

runtime params:  ['self', 'file', 'length', 'extension', 'kwargs']
docstring names: src_ip  -> True
                 dst_ip  -> True

docs/source/pcapkit/protocols/internet/ipv6_route.rst automethod's it, so the rendered page shows the true signature beside an Args: block naming two parameters a caller cannot pass.

Why this needs a decision rather than a docstring edit

An @overload stub at pcapkit/protocols/internet/ipv6_route.py:353-354 genuinely declares both, as typed keyword parameters:

@overload
def __post_init__(self, file: 'IO[bytes] | bytes', length: 'Optional[int]' = ..., *,
                  extension: 'bool' = ..., src_ip: 'Optional[IPv6Address]'= ...,
                  dst_ip: 'Optional[IPv6Address]'= ..., **kwargs: 'Any') -> 'None': ...

So the docstring is consistent with the type surface and inconsistent with the implementation. Deleting the two Args: lines would put the docstring in direct contradiction with the overload directly above it — which is why #501 left it alone rather than "fixing" it into a different inconsistency.

Grepped pcapkit/ and tests/ for both names: they appear only in that overload and in this docstring. Nowhere else in the codebase reads, writes, or passes either. That reads as dead or unfinished plumbing rather than a documentation slip.

The three ways out, none of which is obviously right

1. Implement them. If src_ip/dst_ip were meant to let a caller supply the enclosing IPv6 header's addresses — plausible, since RPL Source Route decompression needs them — then the overload is the intent and the implementation is what is missing. This is the only option that makes the docstring true as written.
2. Delete them from the overload too, and from the docstring. Correct if the idea was abandoned.
3. Keep the overload, fix the docstring to document only what can be passed, and record why the overload is wider.

Someone with the history should pick. Option 1 is the only one that is a feature; 2 and 3 are bookkeeping, and 2 is a (narrow) type-surface break.

Recorded so the sweep is not re-run over it

The same sweep checked IPv6_Route's sibling methods and every other Args: block across six classes — 320 methods, with only this one pair left standing after #501 merged. Three further flags were false positives and are also settled: PCAPNG.__index__'s self is a deliberate Optional[PCAPNG] = None hack (documented in the code) letting it serve as both instance method and pseudo-classmethod, and PCAPNG.read's _read/_seek_set are documented as RST-escaped \_read:/\_seek_set:, which a naive regex misses.

[JarryShaw]

This discrepancy is intentional. The actual code takes anything but the doc and type stub shows what's supported (optional), so that we don't have to directly deal with defaulting keyword args in the code logic.

[JarryShaw]

Closing as answered — by design, per your comment above.

For the record, the discrepancy was verified against the code rather than taken on the docstring: IPv6_Route.__post_init__ accepts anything, while src_ip/dst_ip appear only in an @overload stub, which is what documents them as optional without the runtime having to default them. pcapkit/protocols/internet/ipv6_route.py:353-380 is the relevant range, and the pattern recurs elsewhere in the library exactly as you expected it would.

Reopen if you would rather the stub and the runtime be brought into line instead.