Repository navigation
Reorder protocol class members to the member-order convention #2490
Description
Reorder protocol class members on main to the member-order convention. Ruled by the owner: HTTP v1 is a violation; dunders (__init__, __new__, __post_init__, __index__, __length_hint__, and the rest) are Data Models; the old protocols (IPv4, TCP, UDP, ARP, Ethernet, IPv6) are the reference.
Order inside a protocol class body: properties, public methods (id, read, make, register_*), dunders (Data Models), then utilities (_read_xxx before its _make_xxx).
Landed violations (ref: audit on 545ad0ca7): application/application.py, application/httpv1.py (HTTP), application/httpv2.py, application/ospf.py, application/ssl.py, data/application/httpv2.py, internet/esp.py, internet/hip.py, internet/ipv6_route.py, internet/ipx.py, internet/mh.py, misc/pcap/frame.py, misc/pcap/header.py, misc/pcapng.py, protocol.py (ProtocolBase), schema/misc/pcapng.py, schema/schema.py, transport/sctp.py.
Open PR-only violations are fixed by each PR's own rework (#2444, #2446, #2465, #2466).
Mechanical reorder only; no behaviour change. Split by file group, one PR per group.
Activity
JarryShaw commentedon Oct 31, 2026
Held: Actions queue at 78 (well above the hold line). The member-order reorder dispatches when the queue drops below 40.
refactor(protocols): move HTTP private helpers into Utilities
refactor(protocols): order application protocol members (#2491)
JarryShaw commentedon Nov 1, 2026
Dispatched now; the Actions queue is below the hold line. The worker re-audits current main, makes one branch per file group, and AST-checks each as a pure reorder. Files that other streams are editing right now are deferred until those land: the LinuxSLL/ARPHRD link files, IGMP, the checksum protocols, DTLS, and IPX/Loopback/SCTP for the registry work.
JarryShaw commentedon Nov 1, 2026
Decisions needed for the rest of this issue. protocol-member-order.rst does not settle these:
read()normake()calls and no registry reaches (e.g.HTTPv1._decode_text,PCAPNG._check_block_floor,IPv6._exthdr_key): where do they go? Options: (a) last in Utilities, (b) next to their first caller. Recommendation: (a).read()/make()name directly (_read_*_unknown) were treated as specific readers, as refactor(protocols): order application protocol members #2491's review did. Options: confirm that, or file them as helpers. Recommendation: confirm, and write it on the page.JarryShaw commentedon Nov 1, 2026
JarryShaw commentedon Nov 1, 2026
Owner took all five recommendations, paraphrased:
read()normake()calls and no registry reaches goes last in Utilities.read()/make()name directly (_read_*_unknown) count as specific readers, and the page says so.Reconciled: items 1, 2 and 3 are written onto protocol-member-order.rst, and item 5's guard test is dispatched now in one PR. That guard carries a known-exceptions table, so it passes on main today and keeps passing as #2522, #2523 and the held link/misc branches merge. Applying item 1's moves and rule c is another mechanical reorder of the same files, so it follows in its own PRs once the in-flight streams release them (the checksum, TLS, HTTP, IGMP and link streams).
15 remaining items
docs(changelog): fold main's latest merge wave into 1.6.0 (#2449)
JarryShaw commentedon Nov 2, 2026
#2586 (checksum move) and #2590 (IGMP names) have both merged, so this is unblocked. A worker is reordering the remaining classes (OSPF, IGMPv3 with its schema classes, IPv4, IPX, IP_Pseudo, SCTP and TCP) and deleting their
KNOWN_EXCEPTIONSentries. Each module comes with an AST-identity proof that the reorder is pure, as the earlier #2490 reorders did.JarryShaw commentedon Nov 2, 2026
The remaining guard exceptions are reordered in #2613, which leaves the guard's
KNOWN_EXCEPTIONSempty. Three parts of the page are not applied anywhere yet, and the guard does not check them: rule c (option readers in their registry's declaration order), subgroup d (helpers thatread/makedo not reach go last) and registry-map entry order. This issue stays open for them, as the earlier thread assigned them to follow-up reorder PRs.JarryShaw commentedon Nov 2, 2026
The remaining items are rule c (option readers in registry declaration order), subgroup d (unreachable helpers last) and registry-map entry order. They reorder members across many protocol modules that open PRs still edit: #2595 (TLS), #2602 (SSLv3), #2603 (DTLS), #2607 (802.11) and #2609 (HTTP/2), plus #2574's family rollout. Blocked: this unblocks when those PRs merge (
gh pr view <n> --json state -q .stateprintsMERGED).JarryShaw commentedon Nov 2, 2026
The PRs this waited on (#2595, #2602, #2603, #2607, #2609) and #2574's rollout have all merged. The reorder touches most protocol modules, so it runs in the serial window with #2594 and #2534, once no open PR edits
pcapkit/protocols/. It staysblocked, but now on that window rather than on those PRs.