-
-
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
Improve typing for unresolved managers #1044
Improve typing for unresolved managers #1044
Conversation
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.
Could we also add a test case having two different unresolvable managers, in the same module, that'll also reveal their model attribute type?
@flaeppe isn't that what this test is checking? django-stubs/tests/typecheck/managers/test_managers.yml Lines 446 to 543 in 2cca99a
|
I've found a bug with this implementation, so hold off on merging until I have that under control :) Edit: Fixed now ✅ |
@sobolevn Any plans to merge this and the few other PRs that should be ready? We're currently running with this branch at work and it's been working fine (both 1.11 and 1.12 is unusable for us due to phantom type errors :(). I also have a few other things on my list to fix (like #960), but I'll get too many merge conflicts so I'm holding off for now |
This changes the logic when encountering an unresolvable manager class. Instead of adding it as a `Manager` we create a subclass of `Manager` that has `fallback_to_any=True` set. Similarly a `QuerySet` class is created that also has fallbacks to `Any`. This allows calling custom methods on the manager and querysets without getting type errors.
Because this inherits from _QuerySet, not QuerySet, it needs to have two parameters
Sorry for the delay, I was on vacation. Can you please resolve merge conflicts? |
d89701d
to
8035abb
Compare
No worries, I assumed as much. The conflicts should be resolved now :) |
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!
This changes the logic when encountering an unresolvable manager class. Instead of adding it as a
Manager
we create a subclass ofManager
that hasfallback_to_any=True
set. Similarly aQuerySet
class is created that also has fallbacks toAny
. This allows calling custom methods on the manager and querysets without getting type errors.