-
-
Notifications
You must be signed in to change notification settings - Fork 454
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce QuerySetAny
type for QuerySet isinstance checks
#1199
Conversation
One concern is that we are forcing end-users to use |
TODO: Add test cases for |
If this gets merged, all downstream users using I understand this is to fix I agree the latter issue deserves to be fixed, but before inflicting such a large migration on users, we should be quite sure there are no better alternatives. Maybe there's something that can be done with mypy plugins to avoid this? |
Yeah, I am also quite worried about this. This seems very high-risk. |
I am also worried about making such a change. We should maintain |
I think we can also do this the other way around, by making |
94b89bd
to
5c0ef2c
Compare
The PR is updated. The approach taken here is making A slight disadvantage of this approach is that |
4979aa1
to
fedc759
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This way we can remove a new class. It might affect some cases like invariant lists.
(Please, also add a test for list[QuerySet].append(query_set_instance_obj)
case).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! Looks great now!
I will let others to provide their feedback before merging.
Renamed the test case to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I think the new name is suitable.
This also re-export `QuerySetAny` for external access to nongeneric QuerySet. The approach taken here is making `_QuerySetAny` an alias of `_QuerySet[_T, _T]` dedicated for isinstance checks, and leave `QuerySet` unchanged as the type alias of `_QuerySet[_T, _T]`. Fixes typeddjango#704. Signed-off-by: Zixuan James Li <[email protected]>
variant of `QuerySet` suitable for runtime type checking: | ||
|
||
```python | ||
from django_stubs_ext import QuerySetAny |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question for other PRs: do we have other types to take care of?
I think this is ready to merge. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, QuerySetAny
also seems like a good name!
QuerySetAny
type for QuerySet isinstance checks
|
This also re-export QuerySetAlias for external access to generic _QuerySet. We use this in our test cases as well. The approach taken here is making
QuerySet
a subclass of_QuerySet[_T, _T]
, and make_QuerySetAlias
a type alias of_QuerySet[_T, _T]
._QuerySetAlias[_T]
should be used internally whenever the type parameter is needed, replacingQuerySet[_T]
entirely within the stubs; bothQuerySet
and_QuerySetAlias
are accepted in use cases where the type parameter is not needed.I have made things!
Related issues