const: eight more files under const/vendor ftp+http still carry the f-string disable

[JarryShaw]

Describe the bug

Eight files under pcapkit/{const,vendor}/{ftp,http}/ still carry # pylint: disable=consider-using-f-string. #817 earns it for the command.py/method.py pair; these are the remainder.

Measured on 55e1b756e:

const/ftp/return_code.py      const/http/error_code.py    const/http/frame.py
const/http/setting.py         const/http/status_code.py
vendor/ftp/return_code.py     vendor/http/frame.py        vendor/http/status_code.py  (x2)

Expected behavior

f-strings throughout, and the disable dropped from every one — at which point the claim "nothing under pcapkit/{const,vendor}/{ftp,http}/ needs it" is finally true. #804's body asserted that prematurely; #817's author caught it, and this issue is the actual remainder.

Additional context

Three of the const/ files inherit their % from a shared template, not from their own generator: const/http/{error_code,frame,setting}.py come from pcapkit/vendor/default.py:55. So converting those three means editing the shared base, which emits far more than these eight files — check the blast radius across every generated const/ module before touching it, and expect that change to want its own PR.

Two traps, both hit on this family today:

• Count % structurally, not textually. My own vendor: three %-formatted __repr__ methods keep the f-string disable alive in ftp.command and http.method #804 table said vendor/ftp/command.py had 3 %-format sites and vendor/http/method.py 2; an AST walk over BinOp(Constant(str) % x) gives 1 each, because inside a LINE = lambda …: f''' template the __repr__ lines are string content. And a %-grep must allow both quote styles — '[^']*%[sdr] reported 0 on files whose every site was double-quoted.
• Check tests/ for assertions that pin the disable as RETAINED. test_const_enum_builtin_parity.py:658 did exactly that for refactor(const): f-string the last three %-formatted __repr__ methods (#804) #817's pair (assertIn('consider-using-f-string', source) plus assertIn('%', source)), so it had to be flipped. Expect the same shape here, and flip rather than delete.

Use pylint with the real Makefile flag set plus useless-suppression to confirm each drop is earned — --disable=all --enable=useless-suppression manufactures false hits.

Related: #804, #817, #798, #783.

[JarryShaw]

Checkable blocker: #817 merged.

gh pr view 817 -R JarryShaw/PyPCAPKit --json state,mergedAt

#817 edits tests/const/test_const_enum_builtin_parity.py (+269/−19), which is the file any work here must also touch — its :658 assertion pins which modules retain the disable, so both changes rewrite the same assertions. #817 is review: pending with a cross-review running, so the hold should be short.

Note the three const/http/{error_code,frame,setting}.py files trace to pcapkit/vendor/default.py:55, a shared template. If that turns out to want its own PR — and it probably does, given how many generated modules it emits — split this issue rather than growing it.

[JarryShaw]

Adding one item found by #817's cross-review: pcapkit/const/http/method.py:2 carries # pylint: disable=line-too-long, which useless-suppression flags as I0021 — a stale disable of a different rule, present on both stock and #817's head, so unrelated to the f-string work and not a regression.

pcapkit/const/http/method.py:2   # pylint: disable=line-too-long

Worth sweeping in the same pass as the eight consider-using-f-string files, since the method is identical: run pylint with the real Makefile flag set plus --enable=useless-suppression over pcapkit/const/ and pcapkit/vendor/, and drop every disable it reports as useless — not just the f-string ones. make pylint cannot see any of this, because useless-suppression is not in its --enable set, which is worth deciding about separately: adding it would catch the next stale disable for free.

Self-test whatever you use: a disable that is genuinely load-bearing must not be reported, or the sweep will strip working suppressions. #817's reviewer confirmed the two consider-using-f-string disables it dropped were genuinely earned before and genuinely unneeded after, by checking both directions.

[JarryShaw]

Restating the blocker, because my own later comment displaced it from being the last one.

Checkable blocker: #817 merged.

gh pr view 817 -R JarryShaw/PyPCAPKit --json state,mergedAt

#817 edits tests/const/test_const_enum_builtin_parity.py (+269/−19), the same file any work here must touch — its dropped tuple is what pins which modules must not carry the disable, and this issue adds eight more to it. #817 is review: good-to-go with CI green, so the hold should be short.

Scope as it now stands: the eight consider-using-f-string files, plus the stale # pylint: disable=line-too-long at const/http/method.py:2 that useless-suppression flags as I0021 on both sides of #817. Three of the eight — const/http/{error_code,frame,setting}.py — trace to the shared pcapkit/vendor/default.py:55 template, so split those out rather than growing this issue.

Noting the mechanism for future reference: a blocker line only counts while it is in the last comment, so any comment added afterwards silently breaks the check. That is the same shape as the cr: trailer problem — appending a paragraph demotes it.

[JarryShaw]

Unblocked — #817 merged at 02:43:34Z as 75c340413, which was the checkable blocker on this issue.

gh pr view 817 -R JarryShaw/PyPCAPKit --json state,mergedAt   # MERGED 2026-09-26T02:43:34Z
git log --oneline -1 origin/main                              # 75c340413

So the eight remaining files under pcapkit/const/ and pcapkit/vendor/ that still carry a %-formatted __repr__ are now free to convert — #817 took the ftp.command and http.method pair, and this is the remainder it deliberately left out of scope.

Dispatching a worker. One thing for whoever picks it up: main moved twice more after #817 (21e9588af, then 75c340413), and two open PRs are live in nearby territory — #827 in pcapkit/corekit/fields/field.py and #828's fix in pcapkit/corekit/fields/numbers.py — so branch from current main and stay inside const/ and vendor/.

[JarryShaw]

Correcting this issue's own scope — "eight files" was wrong in both directions. Found by #830's author, verified by me.

Over-counted. pcapkit/const/http/{error_code,frame,setting}.py have no __repr__ at all — grep -c 'def __repr__' is 0 for each, against 1 for const/ftp/return_code.py as a control. Their % lives in _missing_'s ValueError/extend_enum calls, inherited from pcapkit/vendor/default.py's shared template, which is a different change with a much wider blast radius.

Under-named. {const,vendor}/pcapng/option_type.py does carry a %-formatted __repr__ and this issue never mentioned it, because I scoped the issue to {const,vendor}/{ftp,http}/ from #817's remainder rather than from a search.

So the real set is three pairs, six files: {const,vendor}/ftp/return_code.py, {const,vendor}/http/status_code.py, {const,vendor}/pcapng/option_type.py — which is what #830 converts.

One thing #830 deliberately does not do, and is right not to. #817 removed the module-level consider-using-f-string disable from its pair, because after the conversion nothing in those files needed it. Here the disable must stay — measured on #830's head, each file still has other %-format sites:

const/ftp/return_code.py      5     vendor/ftp/return_code.py      5
const/http/status_code.py    10     vendor/http/status_code.py     4
const/pcapng/option_type.py   5     vendor/pcapng/option_type.py   5

Those are __str__ and _missing_, which legitimately keep %. Removing the disable would red make pylint, so the asymmetry with #817 is correct rather than an oversight.

Still open after #830, and not folded in: the shared vendor/default.py header disable, and the useless-suppression sweep for stale line-too-long on const/http/method.py:2. Those want their own issue.

[JarryShaw]

Correcting my own comment above — the pragma reasoning was wrong for three of the six files.

I wrote that removing consider-using-f-string would red make pylint on all six, citing per-file %-site counts of 5 / 10 / 5 / 5 / 4 / 5. Both halves of that are wrong, found by #830's cross-review and re-derived by me:

• The real counts (from pylint --enable=consider-using-f-string with the pragma stripped, not from grep) are 5 / 0 / 10 / 0 / 6 / 0 for const/ftp, vendor/ftp, const/http, vendor/http, const/pcapng, vendor/pcapng. My values were transposed across the pairs.
• The three vendor/ files have no module-level pragma at all. Theirs sits inside the LINE = lambda template — pragma at :32 / :28 / :31, template starting at :29 / :25 / :28 — so it is template text destined for the generated const/ file. Measured: pragmas BEFORE the template: 0 for all three, against 1 for const/ftp/return_code.py, which has no template; and a stripped vendor/ftp/return_code.py makes pylint fire 0 while a stripped const/ftp/return_code.py fires 6.

The conclusion is unchanged — no dead pragma on any of the six, so #830 correctly changes none of them — but "removing it would red pylint" is only true of the three const/ files. On the vendor half there is nothing to remove.

Worth recording why I got it wrong, because it is the third time today: I counted with a grep where the answer is structural. My column-0-anchored grep reported a module pragma in all six, and it was fooled because the template's own lines also begin at column 0 inside the triple-quoted string. The same class of error produced the bad %-site counts here, the wrong disable-removal count on #817's diff, and the eight-vs-three call-site list on #828.