Is your feature request related to a problem? Please describe.
Filed per @JarryShaw's ruling on #842: "Take (1) then and file tracking for the remaining work and keep on working."
#842 is closed as done at 111 of 127 const enum classes inheriting EnumRegistry. This tracks the remaining 16.
They divide into two groups, measured on main:
4 StrEnum classes ftp/command.FEATCode, http/method.Method, pcapng/option_type.OptionType,
reg/apptype.AppType
12 others ftp/command.CommandType (IntFlag), ftp/return_code.{ResponseKind,GroupingInformation},
http/status_code.StatusCode (all IntEnum), reg/apptype.TransportProtocol,
and the four transport subclasses dccp.DCCP / sctp.SCTP / tcp.TCP / udp.UDP
Each defines its own __new__ and its own hand-written get, so none shares pcapkit/vendor/default.py's template —
which is why #858 could not sweep them up.
The blocker is real, not merely bookkeeping. The base get dispatches on isinstance(key, str) and its str
branch never falls back to the value path. So on a StrEnum registry a valid value that is not a name would
start raising KeyError where the bespoke get resolved it. That was measured during #858's review on a real
EnumRegistry + StrEnum fixture, not hypothesised.
Describe the solution you'd like
Two steps, in order:
- Fix the base's
str-key dispatch so a StrEnum registry can resolve a key that is a valid value but not a
name — try the name path, then fall through to the value path rather than raising. tests/const has no
StrEnum-valued registry on the base today, so this needs a fixture as well as a fix.
- Then convert the 16, or decide per class that its bespoke
__new__ earns an exemption. ftp/return_code and
http/status_code are IntEnum and unaffected by (1), so they could go first.
Describe alternatives you've considered
Converting them without (1), which #858's review showed regresses StrEnum value lookups. Rejected.
Leaving all 16 permanently bespoke. Defensible — they genuinely differ — but it leaves get/get_all/register/
register_alias unavailable on four public StrEnum registries including AppType, which is the one most likely to
be reached for.
Additional context
A second, independent item for the same 16, from #859's review: ftp/return_code.py:284,299 and
http/status_code.py:250,265 still carry their own -1-as-no-default convention (if default == -1: raise). After
#859 the 111 treat -1 as an ordinary value, so the repo will hold two meanings for a literal -1 default (plus
a third, value-to-mint, at pcapng/option_type.py:201 and six sites in protocols/). Harmonising that belongs here
too.
Related: #842 (closed, the 111), #858 (the template move), #859 (the NO_DEFAULT sentinel), #775 (the minting tier).
Is your feature request related to a problem? Please describe.
Filed per @JarryShaw's ruling on #842: "Take (1) then and file tracking for the remaining work and keep on working."
#842 is closed as done at 111 of 127 const enum classes inheriting
EnumRegistry. This tracks the remaining 16.They divide into two groups, measured on
main:Each defines its own
__new__and its own hand-writtenget, so none sharespcapkit/vendor/default.py's template —which is why #858 could not sweep them up.
The blocker is real, not merely bookkeeping. The base
getdispatches onisinstance(key, str)and itsstrbranch never falls back to the value path. So on a
StrEnumregistry a valid value that is not a name wouldstart raising
KeyErrorwhere the bespokegetresolved it. That was measured during #858's review on a realEnumRegistry+StrEnumfixture, not hypothesised.Describe the solution you'd like
Two steps, in order:
str-key dispatch so aStrEnumregistry can resolve a key that is a valid value but not aname — try the name path, then fall through to the value path rather than raising.
tests/consthas noStrEnum-valued registry on the base today, so this needs a fixture as well as a fix.__new__earns an exemption.ftp/return_codeandhttp/status_codeareIntEnumand unaffected by (1), so they could go first.Describe alternatives you've considered
Converting them without (1), which #858's review showed regresses
StrEnumvalue lookups. Rejected.Leaving all 16 permanently bespoke. Defensible — they genuinely differ — but it leaves
get/get_all/register/register_aliasunavailable on four publicStrEnumregistries includingAppType, which is the one most likely tobe reached for.
Additional context
A second, independent item for the same 16, from #859's review:
ftp/return_code.py:284,299andhttp/status_code.py:250,265still carry their own-1-as-no-default convention (if default == -1: raise). After#859 the 111 treat
-1as an ordinary value, so the repo will hold two meanings for a literal-1default (plusa third, value-to-mint, at
pcapng/option_type.py:201and six sites inprotocols/). Harmonising that belongs heretoo.
Related: #842 (closed, the 111), #858 (the template move), #859 (the
NO_DEFAULTsentinel), #775 (the minting tier).