Repository navigation
Runtime use of type_check_only classes should give an error #9531
Description
Feature
Currently Mypy doesn't seem to care whether a class is marked with type_check_only in a stub file. My proposal is that any runtime use of such a class should produce an error, including importing it outside of if TYPE_CHECKING and using it in annotations without quotes or from __future__ import annotations.
Pitch
To create stubs for libraries that define classes dynamically, it's pretty much required to create classes in stubs that don't exist at runtime. Marking these with type_check_only lets you show that these classes can't be used at runtime, but consumers of your stubs could easily still do so accidentally. It would be useful if Mypy could warn them in those cases.
Activity
gvanrossum commentedon Oct 4, 2020
Can you provide an example? Do you have a specific package in mind?
henribru commentedon Oct 5, 2020
Sure. The specific package that prompted me to suggest this is https://github.com/googleapis/google-api-python-client, which I've been working on generating a stub package for. There are two different aspects of this library where this would be useful:
Dynamically generated classes
All API resources represented by this library are instances of the Resource class that have had methods dynamically created and attached at runtime based on an API schema. To be able to annotate this I generate "fake" subclasses of
Resourcein the stub files, one for each of the possible dynamically createdResourceinstances. If the users of my stubs accidentally use one of these subclasses from my stubs in a runtime-context (which could be as simple as forgetting to quote their annotations), their code won't work. It would be useful if Mypy could warn them about this. I was actually a bit surprised when it didn't, because my understanding wastype_check_onlyis precisely for the case where a stub defines somethings that doesn't exist at runtime.You can see some examples of the classes I've had to generate here: https://github.com/henribru/google-api-python-client-stubs/blob/master/googleapiclient-stubs/_apis/sheets/v4/resources.pyi
There's tons of other files like that, but at runtime there's only
Resource.Another case I know of where this is relevant is https://github.com/boto/boto3. It doesn't stick everything onto instances of a single class, but dynamically creates subclasses, which leads to the same kinds of annotations. This stub package looks like it has the same issue as mine of having to include stub-only classes. I'm sure there are many other examples too, but it might be especially prevalent in these kinds of API wrappers.
Object-like dicts
This is probably the more common case. Lots and lots of libraries use dicts as a sort of quasi-object for argument and return types. When creating stubs for these it's really helpful to include
TypedDictsubclasses for those uses, but again, these won't be available at runtime when they're only present in stub files and it would be nice if Mypy warned you about this.You can see examples here of this case: https://github.com/henribru/google-api-python-client-stubs/blob/master/googleapiclient-stubs/_apis/sheets/v4/schemas.pyi. These are only available in the stub package, so users of the stubs need to take care about where they use them.
gvanrossum commentedon Oct 5, 2020
Yeah, that's not an unreasonable feature request. Are you interested in implementing this for mypy?
henribru commentedon Oct 6, 2020
I think that would depend on how challenging it is. Do you have some insight into what it would take to implement?
gvanrossum commentedon Oct 6, 2020
Alas, I don't have time to look into that. I suggest that you try for about an hour and then report what you've learned.
KotlinIsland commentedon Mar 4, 2022
Mypy should inform users that
type_check_onlyisn't supported at all. It's not documented anywhere that support isn't provided.AlexWaygood commentedon Mar 27, 2022
henribru commentedon Mar 27, 2022
@AlexWaygood This isn't a duplicate,
no_type_checkandtype_check_onlyare different things. Please reopen this.AlexWaygood commentedon Mar 27, 2022
Sorry, my bad, I misread!