[stubtest] Check runtime availability of private types not marked @type_check_only#19574
[stubtest] Check runtime availability of private types not marked @type_check_only#19574brianschubert wants to merge 4 commits intopython:masterfrom
@type_check_only#19574Conversation
|
python/typeshed#14512 addresses the new stdlib hits in typeshed thirdy-party stub hits can be seen at https://github.com/brianschubert/typeshed/actions/runs/16697076815/ |
|
These are the third-party stub hits if anyone is interested in investigating some (I'll be sifting through them as I have time) Details |
|
Marking this as ready for review.
|
|
Thanks for taking a shot at this ! It's something I've been wanting for a while as well. This works towards #15146 |
Currently, stubtest ignores symbols that are 1) private and 2) not present at runtime. Private names are often used for stub-only constructs (which we don't want stubtest to complain about), but they can also denote actual private runtime types. Without other context, it's often ambiguous which category a private names falls into. For class definitions, we can make the intent explicit by decorating the class with
@type_check_only. Typeshed already does this for the most part, but there's still quite a few cases of stub-only private types that aren't marked@type_check_only(especially in older stubs).Going forward, I think it could a good idea to make stubtest start checking for
@type_check_onlyon private types that are not available at runtime.A few special cases are needed to avoid false positives on types that cannot be marked with
@type_check_only, namely:This PR creates quite a few new errors on typeshed (~100 in stdlib, ~300 in third-party stubs), which we'll probably want to sift through before merging this. So far I've gone through the stdlib hits, all of which seem to be true positives that we'd want to update.