Context
During PR #224's 20-agent multi-dimensional review, the C20 finding led to introducing a TokenLike Protocol (now wool.TokenLike) mirroring the stdlib contextvars.Token public surface — hiding the Wool-internal id / chain_id / used attributes behind the concrete Token class. The remediation plan deferred the analogous treatment of ContextVar and Context to a follow-up issue.
The follow-up
Extend the stdlib-parity narrowing C20 applied to Token to the other two core context types:
ContextVarLike[T]
Mirror contextvars.ContextVar (name, get, set, reset). Wool's concrete ContextVar already satisfies it structurally. Both should be public: wool.ContextVar stays the concrete user-instantiable class (carrying namespace and other Wool extras); wool.ContextVarLike is the narrow Protocol for users writing def use_var(var: ContextVarLike[int]) — "stdlib OR wool" type hints.
ContextLike
Mirror contextvars.Context (__getitem__, __contains__, __iter__, __len__, get, keys, values, items, run). Wool's concrete Context does not satisfy it today (snapshot dataclass — no dict-like methods, no run). Two sub-decisions for this issue:
- (a) Grow Wool's
Context to satisfy ContextLike by adding dict-like methods + run(). Bigger change — run() interacts with mount/unmount and the chain-contention guard; needs careful design.
- (b) Define
ContextLike for documentation/contract only; Wool's Context does not claim to satisfy it. Cheap; establishes vocabulary without forcing structural conformance.
Why this was deferred
Token's "Protocol replaces concrete" works because tokens are never user-instantiated; for ContextVar this asymmetry forces both Protocol and concrete to coexist, doubling the type-name surface. ContextLike (a) is a meaningful API expansion that deserves its own design pass and tests. None of this was required for the stdlib-parity goals PR #224 closed.
Reference
Context
During PR #224's 20-agent multi-dimensional review, the C20 finding led to introducing a
TokenLikeProtocol (nowwool.TokenLike) mirroring the stdlibcontextvars.Tokenpublic surface — hiding the Wool-internalid/chain_id/usedattributes behind the concreteTokenclass. The remediation plan deferred the analogous treatment ofContextVarandContextto a follow-up issue.The follow-up
Extend the stdlib-parity narrowing C20 applied to
Tokento the other two core context types:ContextVarLike[T]Mirror
contextvars.ContextVar(name,get,set,reset). Wool's concreteContextVaralready satisfies it structurally. Both should be public:wool.ContextVarstays the concrete user-instantiable class (carryingnamespaceand other Wool extras);wool.ContextVarLikeis the narrow Protocol for users writingdef use_var(var: ContextVarLike[int])— "stdlib OR wool" type hints.ContextLikeMirror
contextvars.Context(__getitem__,__contains__,__iter__,__len__,get,keys,values,items,run). Wool's concreteContextdoes not satisfy it today (snapshot dataclass — no dict-like methods, norun). Two sub-decisions for this issue:Contextto satisfyContextLikeby adding dict-like methods +run(). Bigger change —run()interacts with mount/unmount and the chain-contention guard; needs careful design.ContextLikefor documentation/contract only; Wool'sContextdoes not claim to satisfy it. Cheap; establishes vocabulary without forcing structural conformance.Why this was deferred
Token's "Protocol replaces concrete" works because tokens are never user-instantiated; for
ContextVarthis asymmetry forces both Protocol and concrete to coexist, doubling the type-name surface.ContextLike(a) is a meaningful API expansion that deserves its own design pass and tests. None of this was required for the stdlib-parity goals PR #224 closed.Reference