fix(reg)!: drop TransportProtocol's IntFlag base now that nothing composes

[JarryShaw]

Please follow the guide below

• Searched for similar pull requests
• Followed the coding style (make mypy, make isort; ran both directly against the changed files)
• make test passes, and a test case covers the change (scoped to tests/const/, tests/foundation/registry/, tests/vendor/, tests/dumpkit/ per the affected trees)
• Added a changelog entry under docs/source/changelog/ — N/A, changelog centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

What is the purpose of your pull request?

• fix — corrects a defect

---

Description of your pull request and other information

Closes #808. Unblocked by #806, which merged as #815 and retyped every member's proto to a single transport — leaving nothing that builds or relies on a composite TransportProtocol value. The premise was verified with an AST sweep (validated against a known-positive control) plus the maintainer's own AST-sweep test before anything was touched.

This is a breaking change. TransportProtocol's base moves from aenum.IntFlag to a plain aenum.IntEnum, so &, ^, ~ and |'s member-composing behaviour are gone — tcp | udp falls through to int.__or__ and returns a bare int. The four transports keep their exact existing values (tcp=1, udp=2, sctp=4, dccp=8, undefined=0), not renumbered. _missing_ is removed: a plain IntEnum already rejects an undeclared value, so TransportProtocol(3) now raises ValueError where it used to compose tcp|udp. Also breaking and easy to miss: list(TransportProtocol) now yields all five members instead of four, because Flag hid the zero-valued undefined from iteration and plain IntEnum does not. Every member's own repr/str/.name/.value stay byte-identical, and nothing in pcapkit iterates the class bare — only through __members__, which is 5 either way.

Two maintainer rulings on this PR shaped the rest of it, beyond what #808 asked for.

First: "Do not allow extension of TransportProtocol at all." TransportProtocol.get no longer mints on a miss — the extend_enum call and the max_val computation are gone, and an unrecognised name raises ValueError. That closes a pre-existing defect on the way past: because .get() lowercases but does not strip, tcp and tcp used to mint permanent members literally named ' tcp' and 'tcp '. They now raise. Whether to strip was considered and ruled against, to keep the convention engine selection already sets at extraction.py:922, which lowercases only.

Second: "since it's no longer a Flag, | joined values are no longer parsed and accepted, we will treat it as a whole, instead of splitting." AppType._dispatch no longer decomposes proto through show_flag_values; a value that names no registry is refused whole. show_flag_values and ProtocolError are consequently unused here and their imports are dropped.

User-visible exception-type change. AppType.get(80, proto=3) and proto=17 both raised ProtocolError before and both raise ValueError now — 3 names no transport protocol registry of AppType. A bare int was off-contract before this PR (proto: TransportProtocol | str); the annotation now includes int, so this is a change on a newly supported input rather than a regression. Two smaller moves in the same direction: proto=None and proto=2.5 raised TypeError before — from ~ inside the bit decomposition — and now raise ValueError. One move the other way, and the only input anywhere that went from raising to resolving: proto=1.0 and proto=2.0 raised TypeError before and now return http [80 - tcp] and http [80 - udp], because hash(1.0) == hash(TransportProtocol.tcp) and the registries dict is int-keyed. A float is off-contract either way; stock's rejection was an accident of ~ and the new acceptance is an accident of dict hashing, so neither is designed behaviour.

pcapkit/foundation/registry/protocols.py is touched for one comment only, no behaviour: its NOTE justified preferring __members__ over TransportProtocol[...] on the grounds that Flag.__getitem__ silently composes 'tcp|udp' into 3 and that the class is an IntFlag — both false once the base is dropped. The guard itself is still right and unchanged: __getitem__ raises a bare KeyError where this function's contract is RegistryError, and a bare int still hashes and compares equal to its matching member.

Untouched: the four per-transport generated registries. Re-pinned after measuring rather than assuming: tests/dumpkit/test_nameless_enum_rendering_unit.py's sweep at 7→6 flag registries and 4→3 _missing_ field widths, with len(nameless) deliberately left at 5 because TransportProtocol was never in that set.

Applied identically to the vendor generator template, with the rendered output diffed against the committed const file to confirm they still agree byte-for-byte.

Tests: an unrecognised name refused rather than minted, a |-spelled string refused as an ordinary unknown, a bare-int composite refused whole, TransportProtocol no longer extensible at runtime, and the base/value/iteration-count pins — each checked to fail before the change and pass after.

[JarryShaw]

NEEDS CHANGES — changing .get()'s extension from max_val * 2 to max_val + 1 breaks the single-bit invariant that _dispatch still depends on, because show_flag_values is still used to interpret proto.

Measured on this head (1c6d93c41) against 3118ed796, each in its own worktree:

                  PR #836                                         stock 3118ed796
get('bogus') ->   value=9   bits=[1, 8]                            value=16  bits=[16]
AppType.get(80, proto=it):
  PR     -> ProtocolError: tcp|dccp names 2 transport protocols, and so 2 registries…
  stock  -> ValueError: <TransportProtocol.bogus: 16> names no transport protocol registry

get('quux') → 10 → udp|dccp; get('zork') → 11 → tcp|udp|dccp. Every value from 9 up is multi-bit, so every minted member now takes the composite branch and names transports the caller never mentioned. AppType.get(80, proto='tcp|udp') reports tcp|dccp for the same reason.

The root error is keeping show_flag_values on a type that is no longer a flag. Since a composite can no longer be a member, _dispatch should test proto against the four real registries directly and let anything else — bare int or minted member — fall into "names no transport protocol registry".

Two more, smaller:

• list(TransportProtocol) goes 4 → 5: Flag hid the zero pseudo-member, IntEnum does not. Nothing in-tree iterates it (apptype.py:63 uses __members__, 5 on both), so it is not a break, but a breaking PR body should say it.
• TransportProtocol.get('tcp|udp') still mints a junk member rather than refusing. register_apptype refuses it; the const class's own .get() does not.

[JarryShaw]

Fix pushed as 2fba732bc (amended, one commit on 3118ed796). Verified independently — every branch measured on the new head:

list(TransportProtocol)              ['undefined','tcp','udp','sctp','dccp']   (5, disclosed in the body)
TP.get('tcp|udp')                    ValueError: 'tcp|udp' is not a valid TransportProtocol   (no longer mints)
TP.get('bogus') -> 9
AppType.get(80, proto=minted member)  ValueError: <TransportProtocol.bogus: 9> names no transport protocol registry
AppType.get(80, proto=TP.tcp)         <TCP.http: 80 [tcp]>
AppType.get(80, proto='tcp')          <TCP.http: 80 [tcp]>
AppType.get(80, proto=bare int 3)     ProtocolError: tcp|udp names 2 transport protocols…   (correct text now)
AppType.get(80, proto=bare int 17)    ValueError: 17 names no transport protocol registry   (stray bit)

So a minted member no longer gets bit-decomposed, and the bit-decomposition path survives only for a genuine bare int all of whose bits are real transports — which is the pre-existing tested behaviour for hand-built composites. The tcp|dccp-for-tcp|udp misreport is gone.

The third flag-count pin is fixed and the two previously-untested pins were measured rather than guessed: registries 7 → 6, nameless unchanged at 5 (TransportProtocol was never in the nameless set), widths 4 → 3. I re-derived the registry count independently — exactly 6, the survivors being CommandType, Flags and the four mh flags — and tests/dumpkit/test_nameless_enum_rendering_unit.py now runs 6 tests, all OK. Stale prose in that file updated too.

Back to review: pending for the new head; a cross-review is running.

[JarryShaw]

Cross-review (sonnet) on 2fba732bc: GOOD TO GO on the code — all seven items confirmed. Generator/const agreement proven properly by rendering the template's BASE(...) and diffing all three regions outside the TABLE/MISS insertion points, byte-empty each time. _missing_'s removal changes nothing: TP(99), TP(None), TP(-1) and a string all raise ValueError identically on both trees, and True/False/1.0/0 resolve identically; only TP(3) differs, which is the fix. Sequential minting collides with nothing, re-requesting a minted name returns the same object, and the | refusal catches nothing legitimate — on stock those same inputs silently minted members literally named 'tcp|udp'. register_apptype still refuses a composite, now as RegistryError: unknown transport protocol: 3. 104 tests under pytest, cross-checked at 104 under plain unittest.

Two narration fixes wanted before this is ready, both verified by me:

stock first mint   value=16  bits=[16]    <-- single-bit; stock never misreads as a composite
PR   first mint    value=9   bits=[1, 8]

1. test_a_minted_protocol_names_no_registry_rather_than_a_composite's docstring narrates the "misread as composite" defect as a property of stock. It is not — stock's max_val * 2 always lands on a single bit, so the defect existed only in this PR's own intermediate round. The test does fail on stock, but at assertEqual(int(minted), 9), not at the ProtocolError assertion the prose describes. Same objection I raised on fix(reg,corekit): retype the registry NULL sentinel and raise ProtocolError from ModuleDescriptor.klass #835's doc page: prose that asserts something untrue sends the next reader down a wrong path, and nothing will surface it.
2. The commit message claims "89 tests via plain unittest"; the measured figure is 104, matching pytest's own total.

One pre-existing defect, out of scope here, recorded so it is not lost: TP.get(' tcp') and TP.get('tcp ') mint junk members named ' tcp' and 'tcp ' rather than resolving to the real tcp, identically on both trees (stock 32/64, PR 10/11) — while TP.get('TCP') correctly case-folds. That belongs to #775, which unblocks when this merges.

[JarryShaw]

GOOD TO GO — amended to 3567359e2, and the earlier code verdict carries because this round changed no code at all.

git diff --stat 2fba732bc 3567359e2 -- pcapkit/     -> empty
git diff --stat 2fba732bc 3567359e2                 -> tests/const/test_const_apptype_split_unit.py | 25 +/ 9 -

Every changed line is docstring prose. The corrected docstring now states the thing I asked for and states it accurately: the misread-as-composite defect existed only in an intermediate round of this PR, stock 3118ed796's max_val * 2 keeps every minted value a fresh single bit (16, 32, 64, …) so the coherent "names no registry" branch always fires there, and the test fails on stock only because the two minting schemes disagree on a number — at assertEqual(int(minted), 9) with AssertionError: 16 != 9 — not because stock shares the defect. Test assertions unchanged.

The commit message's count is corrected to 104 tests under plain unittest (77 tests/const/ + 15 registry + 6 vendor generator + 6 dumpkit), matching pytest's own total. The earlier "89" came from running four individual files inside tests/const/ rather than the directory.

Zero stash entries in the main checkout and the worker's worktree; no leftover scratch worktrees.

Granting review: good-to-go. I will report it ready to merge once CI completes on this head — the label tracks the verdict, inc=0 gates the readiness call.

[JarryShaw]

Merged-together integration check — clean. CI only ever proved each PR alone: #834, #835 and #836 were all cut from 3118ed796, so whichever of them merges second and third meets a main it was never tested against. That matters for this pair specifically, because #836 established that pcapkit/foundation/registry/protocols.py needed no change against main — not against #835's rewritten version of it.

Merged all three into a scratch worktree at origin/main: no conflict, 15 files, +1306 −295. Targeted suites on the combined tree, pcapkit.__file__ asserted inside it:

tests/foundation/registry                      19 tests   OK
tests/const                                    77 tests   OK
tests/corekit                                 240 tests   OK (skipped=16)
tests/dumpkit/test_common_unit                 14 tests   OK
tests/dumpkit/test_nameless_enum_rendering      6 tests   OK
tests/dumpkit/test_plist_escaping_regression    4 tests   FAILED (errors=6)  <-- pre-existing

That last one is not this change. Verified with a stock control — a clean origin/main worktree gives the same 6 errors and the same cause: FileNotFoundError: sample capture 'test.pcapng' not found … most of the sample captures are generated, not committed. A fresh worktree simply has no fixtures until python examples/generators/make_samples.py runs.

So 356 tests pass on the combined tree with zero failures attributable to the merge, and the three may be merged in any order.

[JarryShaw]

Do not allow extension of TransportProtocol at all.

[JarryShaw]

Taking this as a ruling — TransportProtocol stops being extensible. Checked what depends on minting first, and it is narrow:

• The only in-tree caller is _dispatch's own TransportProtocol.get(proto.lower()) (apptype.py:2400, and the generator's copy at vendor/.../apptype.py:355), reached only when proto arrives as a str. So refusing an unknown name turns a silently-minted junk member into a ValueError at that one site.
• Nothing else calls .get() with a name that could miss; tests/vendor/test_vendor_reg_apptype_generator_unit.py:183 pins the call-site count at 1, which a changed miss path does not disturb.

This also subsumes the pre-existing defect I recorded on #775: TP.get(' tcp') and TP.get('tcp ') currently mint members literally named ' tcp' and 'tcp ' because .get() lowercases but does not strip. With extension gone they raise instead, so that case dies here rather than waiting for #775.

Sending it back to implement: drop the extend_enum call and the max_val computation, refuse an unrecognised name the same way the | case already does, and fold the two probes that currently assert minting (TP.get('bogus') -> 9 and the minted-member _dispatch test) into assertions that it is refused. _dispatch's bare-int composite branch stays — a bare int can still reach it by hand even when no member can be minted.

review: good-to-go withdrawn until that lands.

[JarryShaw]

debating but maybe we should strip the protocol after lower cased as well?

[JarryShaw]

Measured the question rather than guessed, and my recommendation is refuse, do not strip — but it is a judgement call and one word from you overrides it.

There is no house precedent for stripping. Across pcapkit/const/ (132 enum files), zero use .strip() anywhere, and TransportProtocol.get is the only one that case-folds at all. The other two get() shapes differ from each other, let alone from this one:

pcapkit/const/tcp/flags.py:80      return Flags[key]        # exact, no folding at all
pcapkit/const/ftp/command.py:306   name = key.upper()       # folds, then STILL mints on miss
pcapkit/const/reg/apptype/…:76     key.lower()              # folds, minting removed by your ruling

And no in-tree source can produce a padded name. proto reaches .get() only as a keyword argument to AppType.get / register_apptype — programmatic, not parsed text — and the generator never calls .get() with IANA column data at generation time; tests/vendor/test_vendor_reg_apptype_generator_unit.py:183 pins the generated base module to exactly one TransportProtocol.get( call site. So ' tcp' can only arrive from a caller bug.

The asymmetry that decides it for me: before your ruling ' tcp' silently minted junk, which is the actual defect. After it, ' tcp' raises ValueError — loud and correct. Stripping would make it succeed, which is a third behaviour and the only one that hides the caller's mistake. .lower() earns its keep because IANA canonically spells TCP while members are lowercase; there is no equivalent upstream that emits whitespace.

One scoping note so the ruling is not over-applied: ftp/command.py:306 still mints on a miss, and should — FTP commands are genuinely open-ended, whereas this registry is partitioned over a closed set of four transports. Dropping extensibility is right here and would be wrong there.

Labelling needs: decision and holding the worker on the refuse path meanwhile. Say the word and I will add .strip() instead.

[JarryShaw]

Commented in the main thread.

[JarryShaw]

And yes, follow house convention and thus your recommendation.

[JarryShaw]

Confirmed and already in flight — no .strip(), following the engine-selection convention (extraction.py:922 lowercases only; no .strip() anywhere in pcapkit/foundation/). needs: decision is cleared.

One thing I should not overstate: your "yes, follow house convention and thus your recommendation" landed ten seconds after I posted a separate reading in the main thread, so I am treating it as confirming the .strip() recommendation only, not the other one.

Still my assumption rather than your ruling, flagged there and repeated here so it does not slip through: I read "treat it as a whole, instead of splitting" as covering the bare-int path too, so _dispatch stops decomposing proto via show_flag_values and a bare 3 will report "3 names no transport protocol registry" instead of "tcp|udp names 2 transport protocols". It is the coherent consequence of having no Flag base and it drops the last show_flag_values use from the apptype family — but it does change a user-visible message on an on-contract input, so one word reverses it if you meant only the string side.

[JarryShaw]

Added two inline comments

[JarryShaw]

NEEDS CHANGES — amended to a5539ed26, rebased onto ad4805f5f, one commit. Your ruling is implemented and every branch measured, but the change left a dead code path behind.

Verified on the new head:

get('bogus') / 'tcp|udp' / ' tcp' / 'tcp ' / '|'   ValueError (no minting)
get('TCP') / get('tcp')                            <TransportProtocol.tcp: 1>
__members__ 5 -> 5 after all probes                not extensible
AppType.get(80, proto='tcp')                       http [80 - tcp]
AppType.get(80, proto=TP.tcp|TP.udp)  (bare int)   ProtocolError: …names 2 transport protocols…

The defect. TransportProtocol.get now ends with two raises that are character-for-character identical:

if '|' in key:
    raise ValueError(f'{key!r} is not a valid {TransportProtocol.__name__}')
raise ValueError(f'{key!r} is not a valid {TransportProtocol.__name__}')

So the '|' branch cannot change any outcome — it is unreachable in effect. Worse, the 11-line NOTE above it (:77-87) still argues that | must be intercepted before minting because a minted composite-named member would lie about being a single transport. Nothing mints any more, so that rationale has evaporated and the comment now describes code that no longer exists — the third round of stale narration on this PR.

Two acceptable shapes, and I have asked the worker to pick one and justify it: delete the branch and its NOTE, folding any surviving rationale into a short comment on the single raise; or keep the branch and give it a genuinely different, more useful message, e.g. naming that 'tcp|udp' looks like a composite and that a port should be looked up under one transport at a time. What is not acceptable is two identical raises with a comment explaining a mechanism that is gone.

Everything else checks out: parent is ad4805f5f, seven files, zero extend_enum and zero .strip() inside get() (extracted by AST — the raw file counts are meaningless, since AppType's own _missing_ legitimately uses extend_enum hundreds of times and the generator's crawler uses .strip() for IANA CSV parsing), no _missing_ on TransportProtocol, key.lower() untouched, zero stash entries.

The needs: decision on stripping is unaffected — still yours, still unimplemented either way.

[JarryShaw]

Dead branch fixed in abee187f7 (one commit, parent ad4805f5f). It took option 2 — a distinct message rather than deleting the branch — and the distinction is real, verified at runtime:

get('tcp|udp') / get('|') / get('a|b')     'X' names more than one transport protocol; resolve
                                           one at a time rather than passing a '|'-joined name
get('bogus') / get(' tcp') / get('tcp ')   'X' is not a valid TransportProtocol

TransportProtocol.get extracted by AST: 0 extend_enum, 0 .strip(), two raises that now differ. __members__ stays 5 across repeated probes. The test pins the distinction in both directions — assertIn('more than one transport protocol', composite_message) and assertNotIn(…, generic_message) at tests/const/test_const_apptype_split_unit.py:1167,1178 — so the branch cannot silently collapse back to dead code. Generator template re-rendered byte-identically; 108 tests across the four selections; mypy 114/38 with an identical error set before and after; isort clean; zero stash entries.

It also removed three stale apptype.py:96 line references it had left in test docstrings and the commit message, which had already drifted from its own edits.

One imprecision I am deliberately not spending a round on: for the pathological input '|', the message says it "names more than one transport protocol" when strictly it names none. The actionable half — don't pass a |-joined name — is correct for that input too, no caller produces a bare '|', and this PR has already had three round-trips, two of them for prose. Flagging it rather than blocking; say the word if you want it tightened.

Head is new, so the previous verdict does not carry: back to review: pending with a cross-review dispatched on a different model from the author. needs: decision stands — the .strip() question is still yours and still unimplemented either way.

[JarryShaw]

All three rulings and F1–F3 land in d2772d17e (one commit, parent ad4805f5f, now eight files since protocols.py came into scope). Verified every branch myself:

get('tcp|udp') / get('bogus') / get(' tcp')   ValueError: 'X' is not a valid TransportProtocol   (one generic refusal)
get('TCP')                                    <TransportProtocol.tcp: 1>
AppType.get(80, proto='tcp') / proto=TP.tcp    <TCP.http: 80 [tcp]>
AppType.get(80, proto=3) / proto=17            ValueError: N names no transport protocol registry of AppType
AppType.get_all(80, proto='tcp')               3 results — identical to stock

Ruling 3 checked for a regression rather than assumed. AppType.get_all(80) and get(80) with the default undefined sentinel raise ValueError on the PR — and identically on stock ad4805f5f, so the sentinel's behaviour is unchanged. I flagged this as a possible regression before measuring it; the stock control refutes that.

show_flag_values and ProtocolError imports are both gone from the const file and the generator. The two remaining textual mentions are a single NOTE that records the history and quotes your ruling verbatim — correct provenance, not stale narration.

F1 fixed with the right reason, not a patched sentence. The replacement NOTE drops both false claims and explains what the guard is actually for: __getitem__ raises a bare KeyError on a miss where this function's contract is RegistryError, and a bare int still hashes and compares equal to its member — IntEnum versus IntFlag changing neither. register_apptype verified still working: member, 'tcp' and case-folded 'TCP' all resolve, 3 gives RegistryError: unknown transport protocol: 3, 'nope' likewise.

F2 fixed — max_val + 1 / "minted 9" are now attributed to this PR's intermediate revision, with stock ad4805f5f's max_val * 2 named as the contrast. F3 fixed — zero 3118ed796 references remain. Generator renders byte-identically (215,013 chars); 108 tests across the four selections; mypy 114/38 with the only diff a +7 line shift in protocols.py from added comment lines; zero stash entries.

For the record, and now in scope since a bare int is on-contract: AppType.get(80, proto=3) and proto=17 were both ProtocolError on stock and are both plain ValueError now. Not a regression — a bare int was off-contract before this PR widened the annotation — but a user-visible exception-type change, and it is the direct consequence of your "treat it as a whole" ruling.

New head, so no verdict carries: review: pending, delta cross-review dispatched.

[JarryShaw]

GOOD TO GO — delta cross-review (opus) on d2772d17e. F1, F2 and F3 all verified fixed, and it could not falsify any of the six new items. One non-blocking finding, which I re-derived:

                stock ad4805f5f                          PR d2772d17e
proto=1.0       TypeError: bad operand type for unary ~   <TCP.http: 80 [tcp]>
proto=2.0       TypeError                                 <UDP.http: 80 [udp]>
proto=2.5       TypeError                                 ValueError  (toward contract)
proto=None      TypeError                                 ValueError  (toward contract)

A float proto now resolves where stock raised — the only input in its 590-row differential matrix that went from raising to resolving. Cause is ordinary dict semantics: hash(1.0) == hash(TransportProtocol.tcp) and __registries__ is int-keyed. A float is off-contract either way (proto: TransportProtocol | str | int); stock's rejection was an accident of ~ and the new acceptance is an accident of hashing, so neither is designed. Not gating on it, and it is now written into the PR body alongside the None/2.5 moves.

The asymmetry I briefed as the worst case has no reachable instance — but with a correction to the reviewer's own numbers. It reported 5 except ProtocolError sites including http.py:139,308,430; I measure 3, at esp.py:1103, http.py:117, ngap.py:1028. Its count and lines are wrong. The conclusion stands: none of those three files references AppType or apptype at all (0 hits each), and every production call site passes a hardcoded member — transport/transport.py:187, schema/transport/{tcp,udp,sctp}.py. So nothing catches ProtocolError from an apptype lookup and would now miss a ValueError.

Also confirmed independently by the review: strings show zero resolution flips and zero exception-type changes across 'bogus', ' tcp', 'tcp ', 'tcp|udp', '|', '', 'TCP|UDP', 'quic' — all raised ValueError on stock too, after minting junk, and raise it now; the 135 int-phase type changes are all the intended composite ProtocolError → ValueError. Generator/const PRE region a 6457-char exact byte match, so neither ruling can be reverted by a regeneration. Overlaying the five test files onto stock gives 10 failed / 72 passed / 39136 subtests. protocols.py's 23-line diff is entirely comment lines.

One number corrected in passing: the const file is 215,014 chars, not 215,013 — a trailing newline, identical on stock, so both figures describe agreement.

Granting review: good-to-go. CI is at 21✅/0❌/6 running on this head; I will report it ready to merge once that completes.

[JarryShaw]

Ready to merge. CI on d2772d17e is complete and clean — 27 ✅ / 0 ❌ / 3 skipped / 0 incomplete at job level — and the PR sits as exactly one commit on top of current main (ad4805f5f, its own parent, so no rebase needed).

State for the record:

head          d2772d17e        one commit, parent ad4805f5f == origin/main
CI            27 ok / 0 fail / 0 incomplete
verdict       GOOD TO GO  (opus delta cross-review; author was sonnet)
labels        fix, test, breaking, refactor, const, review: good-to-go
closes        #808

breaking is on it deliberately: TransportProtocol moves from aenum.IntFlag to aenum.IntEnum, so tcp | udp yields a bare int, list(TransportProtocol) iterates five members rather than four, TransportProtocol(3) raises instead of composing, .get() no longer mints, and composite proto values are refused whole. All of it is in the body, along with the ProtocolError → ValueError change on proto=3/proto=17 and the incidental float widening.

Unpublished decisions left where they belong rather than taken silently: the '|' special case and whitespace stripping were both your calls, recorded on the threads above; the float acceptance is flagged in the body as accidental on both sides rather than designed, so it is visible if you would rather it were guarded.

Merging is yours. When this lands it closes #808, which unblocks #775 and #807, and #816 is expected to dissolve with #775.