Method registered members carry an empty str payload, so Method.GET == GET is False

[JarryShaw]

pcapkit.const.http.method.Method is a StrEnum, but every registered member carries an empty str payload, so comparing one to its own value is False:

Method.GET   value='GET'  str(Method.GET)=''  len=0   Method.GET == 'GET': False

Cause is pcapkit/const/http/method.py:48, inside the class's own __new__:

obj = str.__new__(cls)          # no argument, so the str content is ''

str.__new__(cls) with no second argument builds an empty string, so the member's str content never carries the value even though _value_ does. Every one of the 40 registered members is affected. Reproduced on main at c411d072a and on the current head of #869 alike — it predates both.

Consequence: any caller treating a Method as the string it is (Method.GET == 'GET', '%s' % Method.GET, an f-string, a dict keyed by the verb, str.startswith) silently sees an empty string. The .name and .value attributes are correct, which is why this has gone unnoticed.

Note the interaction with #869: that PR gives unregistered members a real payload (str(Method('frob')) == 'frob'), which leaves registered and unregistered members inconsistent until __new__ is fixed here. Fixing it changes what 40 public members compare equal to, so it is a behaviour change in its own right and belongs in its own review rather than being folded into #869 — see #869 (comment).

Check whether pcapkit/const/ftp/command.py's Command.__new__ and the other hand-rolled __new__s under pcapkit/const/ have the same shape before fixing, and pin the result with a test asserting str(member) == member.value for every member of every str-valued registry.

[JarryShaw]

Checkable blocker: #869 must merge first. The fix here is in pcapkit/const/http/method.py's __new__ and its generator pcapkit/vendor/http/method.py — the same two files #869 is currently editing, on head 517b1775e. Two branches touching them concurrently would conflict, and the later write silently wins.

gh pr view 869 -R JarryShaw/PyPCAPKit --json state,mergedAt -q '"\(.state) \(.mergedAt)"'
gh api "repos/JarryShaw/PyPCAPKit/pulls/869/files?per_page=100" -q '.[].filename' | grep http/method

When that reports MERGED, this unblocks and the work starts from whatever __new__ looks like on main at that point. #869 also lands the unregistered-member half of the same inconsistency, so the diff here shrinks to registered members only.

[JarryShaw]

Unblocked — #869 merged at 12:21:47Z as 60b85e3a4, and it was the only gate. Verified:

gh pr view 869 --json state,mergedAt,mergeCommit  ->  MERGED  2026-09-28T12:21:47Z  60b85e3a4
git log --oneline -1 origin/main                  ->  60b85e3a4 fix(const,vendor): bring 8 bespoke registries onto EnumRegistry, stop them minting (#860) (#869)

The two files this needs — pcapkit/const/http/method.py and pcapkit/vendor/http/method.py — are no longer being edited by another branch, so the conflict that held this is gone. #869 also landed the unregistered-member half of the same inconsistency, which is why the remaining scope here is registered members only: __new__ at pcapkit/const/http/method.py:48 still calls str.__new__(cls) with no argument, so all 40 declared members carry an empty str payload while an unregistered one now carries its value. Dispatching work on it now.