-
-
Notifications
You must be signed in to change notification settings - Fork 434
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
(ManagerClass).from_queryset
is not creating a valid base class
#2224
Comments
If I read what you wrote correctly, here are some relevant references: Some time ago I attempted to introduce support for inheriting (I don't think that it's too generic to understand this form of inheritance for |
a little different from that -- it already works for simple cases (as shown in the testcase in my report) -- just not in our codebase for whatever reason |
I think I may have reduced this problem to a bug (?) in mypy: python/mypy#17402 |
Ah, nice find! Just also want to mention that the plugin doesn't always behave when it comes to generic QuerySets. Not sure if it's affecting anything here though |
had a bit of a breakthrough on the |
I have a fix in #2228 though I'm struggling to write a test to demonstrate the problem -- if you know of some way to force a round of deferral through a cycle it'd probably help me write a test for this |
I've tried to have a look but I have to say that I don't know. I was about to suggest to have a look at
To see if there's some inspiration for testing cycles there. But I realised that you were already involved in those. The only idea I can come up with, while I'm writing this, is that there might be a case when setting up a But I'm totally not sure. |
figured out a way to force deferral! found an example with a |
via #2228 |
Bug report
so I realize this is not the best of reports -- all attempts I've made to make a minimal case do not reproduce the bug so I suspect it is something to do with how our repository is set up somehow.
I have thrown together a reproducible docker image to show the problem:
after the patch is applied this line here should look like this (the dockerfile does this automatically):
and the end of the file should have:
this is one of the custom methods added by our custom base
QuerySet
we technically use a fork of
django-stubs
-- but I've removed that in the docker image above to demonstrate that this is not caused by our patches there (though there will be some additional output because we use django'scache
with strings in a ~somewhat unsafe way).I build and run the docker image via:
docker build -t mypy-repro . docker run --rm -ti mypy-repro
What's wrong
the full output of the above is:
full output
the important bits of that are:
showing that the result of the
from_queryset
manager isn't suitable as a base class (for whatever reason!)I've done a bit of debugging and thrown some prints in mypy and
django-stubs
:this produces the following:
to me this ~maybe points at a bug in mypy in that it's producing the error but with an extra pass it would have resolved the base class? maybe it's somehow a bug here in that we need to indicate the base class should be a higher priority? I don't know
How is that should be
hopefully clear from above, the class should be a suitable base class and the methods from the queryset should be usable.
in a minimal example everything annoyingly works as expected:
System information
python
version: 3.11.9django
version: 5.0.6mypy
version: 1.10.0django-stubs
version: 5.0.2django-stubs-ext
version: 5.0.2The text was updated successfully, but these errors were encountered: