beartype / plum / 33735604152

99%

push

github

fix: Any must not collide with concrete types under beartype>=0.23 (#296)

Fixes #295.

Since `beartype` 0.23.0rc0, `is_subhint(Any, T)` is `True` for every `T`, a
deliberate change matching mypy's two-way assignability semantics for `Any`.
`TypeHint.__eq__` is built from that relation, so `TypeHint(Any) == TypeHint(T)`
became `True` as well. Plum uses those comparisons for two different things.
Dispatch matching wants assignability and is correct as is. Signature
bookkeeping — "is this the same registered signature" (`Signature.__eq__`) and
"is this strictly more specific" (`Signature.__le__`) — needs `Any` to stay a
distinct, least specific type.

Since an unannotated parameter resolves to `Any`, the collision surfaced twice.
Registration silently overwrote the wrong method, in either order and without a
`MethodRedefinitionWarning`, which destroyed plum's own conversion fallback the
moment the package finished importing and broke `plum.convert` globally. And
specificity ordering became registration-order dependent, so a generic `f(x)`
and a specific `f(x: int)` were mutually comparable but neither strictly more
specific, and whichever was registered last won.

Two helpers in `_type.py` fix this. `_type_hint_le` is
`beartype.door.TypeHint(x) <= TypeHint(y)` except that `Any` is a subhint only
of itself, so `X <= Any` still holds for every `X` and `Any` stays the top of
the ordering; `_type_hint_eq` is the corresponding equality. They are used in
`Signature.__eq__`, in both branches of `Signature.__le__`, and in
`add_promotion_rule`'s reverse-rule check. Nothing else changes, so `beartype`'s
assignability semantics are untouched for `Signature.match`, `is_bearable`, and
the public `plum.issubclass`/`plum.isinstance`.

A root `Any` is not the only case. `beartype>=0.23` collapses `list[Any]` onto
`list[int]` exactly as it collapses `Any` onto `int`, so `_substitute_any`
rewrites every nested `Any` to `object` before delegating. For bookkeeping,
`object... (continued)

50 of 52 new or added lines in 4 files covered. (96.15%)

1043 of 1050 relevant lines covered (99.33%)

6.72 hits per line