Repository navigation
const(apptype): six pre-existing %-style raises remain where the tree convention is f-strings #792
Description
Activity
- addedrefactorRestructuring for its own sake — neither a fix nor a new capability (refactor: prefix)Restructuring for its own sake — neither a fix nor a new capability (refactor: prefix)constRegenerated IANA or vendor constant tables; members keep their numeric valuesRegenerated IANA or vendor constant tables; members keep their numeric values
on Sep 25, 2026 Labelling
blockedso it does not read as unheld work.Checkable blocker: #783 merged. This issue edits
pcapkit/const/reg/apptype/apptype.pyandpcapkit/vendor/reg/apptype/apptype.py, and #783 (9aada6af5,review: good-to-go, awaiting the maintainer) rewrites the same_dispatchregion of both. Starting now would either conflict on merge or silently clobber whichever landed second — the two agents editing one file failure mode, which produces no error at all.The line numbers in the body are pinned to
ef859f776and will shift once #783 lands, since its diff is +10/−10 above most of them. Re-derive them rather than trusting them:git grep -n "raise [A-Za-z_]*Error('" -- pcapkit/const/reg/apptype/apptype.pyUnblocks the moment #783 is in.
- addedblockedDeferred pending another issue or decision; see the last comment for what unblocks itDeferred pending another issue or decision; see the last comment for what unblocks it
on Sep 25, 2026 Unblocked — #783 merged at 16:21:43Z as
f41e5f880, which was this issue's written blocker. Confirmed the fix is onmainrather than inferring it from the merge:$ git show origin/main:pcapkit/const/reg/apptype/apptype.py | grep -n "if namespaces:" 2416: if namespaces:Every line number in this issue's body has shifted, exactly as the blocker warned. Re-derived on
f41e5f880:93 raise ValueError('%r is not a valid %s' % (value, cls.__name__)) 2309 raise ValueError('%s holds no members; they belong to its per-transport ' 2375 raise ValueError('%r is not a valid port number for %s' % (key, cls.__name__)) 2420 raise ValueError('%r names no transport protocol registry of %s' 2528 raise ValueError('%r is not a valid %s' % (value, cls.__name__)) 2534 raise ValueError('%r is not a valid %s' % (value, cls.__name__))So the body's
:92, :2308, :2368, :2378, :2478, :2484are all stale — use the six above, or better, re-derive again at whatevermainis when the work starts. Still six, and:2420is the trailingValueErrorin_dispatchthat #783 deliberately left alone.blockedoff,wipon. Dispatching.- addedwipWork in flight - a covering PR is open or an agent is actively on itWork in flight - a covering PR is open or an agent is actively on itand removedblockedDeferred pending another issue or decision; see the last comment for what unblocks itDeferred pending another issue or decision; see the last comment for what unblocks it
on Sep 25, 2026 - removedwipWork in flight - a covering PR is open or an agent is actively on itWork in flight - a covering PR is open or an agent is actively on it
on Sep 25, 2026 - added 7 commits that reference this issue
on Sep 25, 2026
Metadata
Metadata
Assignees
Labels
Projects
- StatusShow more project fieldsDone
Describe the bug
The maintainer's convention, ruled on #783: "id like to keep f-string convention across the library. only use
%substitution when inevitable."Measured, so the gap is explicit:
raise …Error(f'…raise …Error('…' % …)pcapkit/whole treepcapkit/const/reg/apptype/apptype.pyonef859f776So the tree convention really is f-strings and this generated module is the exception. #783 converted the one raise it introduced and deliberately left the six pre-existing ones, to keep a
constdiff over a 12,391-member file reviewable for the thing it was actually doing.The six, on
ef859f776::92,:2308,:2368,:2378,:2478,:2484. Plus three%-formatted dunders (__new__,__repr__,__str__) that the same convention arguably covers.Expected behavior
f-strings for the six raises named above, which is what this issue's title scopes it to.
Narrowed, 2026-09-25. This line originally read "f-strings throughout, and the module-level
# pylint: disable=consider-using-f-stringdropped once nothing needs it" — which over-reached past the title. "Throughout" also covers the three%-formatted dunders (__new__,__repr__,__str__) and theextend_enum(..., '%d' % value, ...)calls, and the disable cannot drop until those and three other bespoke templates are done. Left as written, this issue would close on a PR that meets its title but not its stated criteria. The remainder is #798.Additional context
Two things whoever takes this needs to know, both measured:
pcapkit/vendor/reg/apptype/apptype.py:93isBASE = lambda NAME, DOCS, FLAG, TABLE, MISS, MODL: f'''…— a lambda returning an f-string, not astr.format()template. Braces in the emitted code must therefore be doubled in the template;:243's= {{}}is the existing precedent.AppType.LINKfetches IANA's live CSV, so a crawl would rewrite thousands of unrelated member rows. Hand-edit both files and prove equivalence the way fix(const): refuse a multi-bit proto in AppType._dispatch rather than resolving it LSB-first (#759) #783 did — expandBASEand diff the changed region against the const file, expecting 0 diff lines.Also verify each converted message is byte-identical to the
%form it replaces. #783 checked that for its one raise (147 chars vs 147, string-equal);%rversus!ris the trap.Related: #783, #759.