Skip to content

const: bring the 16 bespoke registries onto EnumRegistry, after fixing the base's str-key dispatch #860

Description

@JarryShaw

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:

  1. 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.
  2. 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).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    constRegenerated IANA or vendor constant tables; members keep their numeric valuesdesignA design or decision issue: a pattern being decided rather than a defect or a requestenhancementIssues requesting a new capability (set by the feature request template)refactorRestructuring for its own sake — neither a fix nor a new capability (refactor: prefix)

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions