...heh. You caught @beartype red-pawed there. Get it, red-pawed? Instead of red-handed? I'll stop now.

So, TypeVar is a known weakness for all runtime type-checkers – @beartype, @pydantic, and typeguard alike. TypeVar was never intended to be supported at runtime, because full-blown TypeVar support kinda requires crazy stuff like capturing the full graph of all types across your entire app stack via mypy-style static analysis — which is too computationally insane to reasonably (read: efficiently) perform at runtime. Like all of the other guys, @beartype mostly just silently reduces TypeVar type hints to typing.Any. What I'm saying is...... @beartype mostly just silently ignores TypeVar type hints. 😭

Thankfully, @beartype can and will eventually support TypeVar in at least a limited fashion. We call this type-stable type-checking (i.e., type-checking that all type variable constraints are satisfied for the current function or method call), just because we can.

Thankfully, this is exactly what you want here. We actually have an open feature request tracking eventual @beartype support for this at #236: "Type-stable callable declarations (i.e., TypeVar constraints isolated to single calls)."

The Future: It's So Bright It Burns the Eyes

@beartype's current roadmap for 2023—2024 looks something like:

#. October, 2023: Officially document our new beartype.claw and beartype.peps subpackages at our ReadTheDocs (RTD)-hosted site.
#. November, 2023: Deeply type-check sets (e.g., set, collections.abc.Set, typing.AbstractSet).
#. December, 2023: Deeply type-check mappings (e.g., dict, collections.abc.Mapping, typing.MutableMapping).
#. January, 2024: Probably Plum-related DOOR stuff like beartype.door.TypeHint support for NumPy type hints.
#. February—gods knows how long, 2024: TypeVar! Finally! At last! @beartype does something you want!

tl;dr: It's gonna be awhile. See everybody in 2024. </sigh>