You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
stubtest: Support type_check_only decorator #15146
I would like stubtest to support checking the type_check_only decorator.
This means something marked with type_check_only that DOES exist at runtime is an error.
And something that DOES NOT exist at runtime, and is marked with type_check_only should pass.
Pitch
Instead of marking stub-only classes and methods as private in typeshed, they can be marked with @type_check_only, which is designed for that exact purpose. Private may or may not be found at runtime, and users sometimes don't have a choice to use them, and basically have to guess whether they need to wrap the import in TYPE_CHECK_ONLY or not.
This would also promote marking as type_check_only special methods that don't exist at runtime, but are added to support some typechecker features, in typeshed.
I'd assume the semantics are that it applies to the whole function, is that what you expect as well?
I can't imagine where you'd want to @type_check_only a single overload 🤔. So yea, I think it would make sense to have one @type_check_only apply to the entire overloaded method. So like @override and final, and not like @deprecated.
Activity
Avasam commentedon Sep 23, 2023
Could I get the
topic-stubtestlabel here?[stubtest] support `@type_check_only` decorator (#16422)
jorenham commentedon Jun 25, 2025
There is partial support for this (at least with
>=1.15.0):mypy/mypy/stubtest.py
Lines 508 to 513 in 16e99de
mypy/mypy/stubtest.py
Lines 1378 to 1383 in 16e99de
But in case of overloaded
@type_check_onlyfunctions, stubtest will still report a false positive "error: ... is not present at runtime":mypy/mypy/stubtest.py
Lines 1163 to 1166 in 16e99de
I just ran into this limitation scipy-stubs, so it would be nice if it would also work for overload functions.
hauntsaninja commentedon Jun 25, 2025
Yeah, looks like sobolevn left this as a TODO in #16422
To answer the question he left, I'd assume the semantics are that it applies to the whole function, is that what you expect as well?
jorenham commentedon Jun 25, 2025
I can't imagine where you'd want to
@type_check_onlya single overload 🤔. So yea, I think it would make sense to have one@type_check_onlyapply to the entire overloaded method. So like@overrideandfinal, and not like@deprecated.@type_check_onlysubtypes ofnumpy.ufunc#20223@type_check_onlysubtypes ofnumpy.ufunc#20223@type_check_onlysubtypes ofnumpy.ufunc#20223