Is your feature request related to a problem? Please describe.
EnumRegistry.get's no default marker is the magic value -1, named as NO_DEFAULT in
pcapkit/corekit/enums.py:64 but still just an int. Raised by @JarryShaw on #855: "I'm wondering if we should
change the NO_DEFAULT to a sentinel object."
There is no correctness bug today, measured on #855's head cb7eb0d94:
NO_DEFAULT consumers : 1 file, 5 lines (pcapkit/corekit/enums.py:64,103,123,140,146)
generated registries still on -1: 108 files, each its own `default: 'int' = -1`
min value across all const : 0 -> -1 is unreachable as a legitimate value
(last line from grep -rhoE '^ [A-Z_0-9]+ = -?[0-9]+$' pcapkit/const | grep -oE '\-?[0-9]+$' | sort -n | head)
The wart it does have: the test is default == NO_DEFAULT, and -1.0 == -1 is True, so get(key, -1.0)
silently means no default rather than defaulting to -1.0. Degenerate — no caller passes a float — but it is
the class of thing a sentinel makes impossible.
Describe the solution you'd like
NO_DEFAULT = object(), with the two comparisons at enums.py:140 and :146 becoming is rather than ==. An
object() cannot compare equal to anything a caller might pass, and no call site needs a new import, since
default keeps its default value. A subclass or an enum member would both be worse — each can still compare equal
to something.
Describe alternatives you've considered
Doing it inside #855, which is where it was raised. Rejected: #855 already leaves pcapkit.const with two
contradictory register contracts — the base guards an already-registered value, the 105 generated registries
still silently alias — and changing only the base's get would add a second base-vs-generated divergence.
Additional context
This belongs to the tier of #775 that rewrites pcapkit/vendor/default.py and regenerates, because that is the
only place the base and the 108 generated registries change atomically. Fold it in beside the register() guard
residue, which has the identical shape.
Deferred by @JarryShaw on #855: "Okay let's save the sentinel change to an issue (existing or new)." Also
recorded as a scoped item on #775.
Is your feature request related to a problem? Please describe.
EnumRegistry.get's no default marker is the magic value-1, named asNO_DEFAULTinpcapkit/corekit/enums.py:64but still just anint. Raised by @JarryShaw on #855: "I'm wondering if we shouldchange the NO_DEFAULT to a sentinel object."
There is no correctness bug today, measured on #855's head
cb7eb0d94:(last line from
grep -rhoE '^ [A-Z_0-9]+ = -?[0-9]+$' pcapkit/const | grep -oE '\-?[0-9]+$' | sort -n | head)The wart it does have: the test is
default == NO_DEFAULT, and-1.0 == -1isTrue, soget(key, -1.0)silently means no default rather than defaulting to
-1.0. Degenerate — no caller passes a float — but it isthe class of thing a sentinel makes impossible.
Describe the solution you'd like
NO_DEFAULT = object(), with the two comparisons atenums.py:140and:146becomingisrather than==. Anobject()cannot compare equal to anything a caller might pass, and no call site needs a new import, sincedefaultkeeps its default value. A subclass or an enum member would both be worse — each can still compare equalto something.
Describe alternatives you've considered
Doing it inside #855, which is where it was raised. Rejected: #855 already leaves
pcapkit.constwith twocontradictory
registercontracts — the base guards an already-registered value, the 105 generated registriesstill silently alias — and changing only the base's
getwould add a second base-vs-generated divergence.Additional context
This belongs to the tier of #775 that rewrites
pcapkit/vendor/default.pyand regenerates, because that is theonly place the base and the 108 generated registries change atomically. Fold it in beside the
register()guardresidue, which has the identical shape.
Deferred by @JarryShaw on #855: "Okay let's save the sentinel change to an issue (existing or new)." Also
recorded as a scoped item on #775.