-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Add special support for @django.cached_property
needed in django-stubs
#18959
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
base: master
Are you sure you want to change the base?
Conversation
mypy/stubtest.py
Outdated
# https://docs.djangoproject.com/en/5.2/ref/utils/#django.utils.functional.cached_property | ||
# This is needed in `django-stubs` project: | ||
# https://github.com/typeddjango/django-stubs | ||
if repr(type(runtime)) != "<class 'django.utils.functional.cached_property'>": |
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.
What do you think of using type(runtime).__name__ == "cached_property"
as a heuristic? That way we're not as specific to one user.
Also out of curiosity, why can't django use @functools.cached_property
directly?
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.
Also out of curiosity, why can't django use @functools.cached_property directly?
No idea 🤷
What do you think of using type(runtime).name == "cached_property" as a heuristic? That way we're not as specific to one user.
I like your idea better, because it does not call __repr__
, which might have side-effects. Of course, .__name__
might also trigger some very complex cases, but they should be extrimelly rare.
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.
Why can't django use
@functools.cached_property
directly?
Django predates python 3.8 by many years, and probably there's little to no benefit from removing their in-house version. A lot (really a lot) of users import cached_property
from Django, so they'll have to maintain an alias anyway.
I will give @JukkaL some time to re-review and will merge it in several days. |
Hi!
We, in
django-stubs
, have a lot of usages of@cached_property
decorator that is a part ofdjango
: https://docs.djangoproject.com/en/5.2/ref/utils/#django.utils.functional.cached_propertyAll usages of it we have to add to
subtest/allowlist.txt
, which is not great. In typing we reuse@functools.cached_property
to have all the benefits of its inference: https://github.com/typeddjango/django-stubs/blob/ee8e8b11c37866969ff0406be20591a067dfa983/django-stubs/utils/functional.pyi#L3-L4But,
stubtest
is not happy with this move: because in runtime objects havedjango.utils.functional.cached_property
type and we see the following error:So, we add all
@django.utils.functional.cached_property
usages to ourallowlist.txt
. There are LOTS of entries there: https://github.com/typeddjango/django-stubs/blob/ee8e8b11c37866969ff0406be20591a067dfa983/scripts/stubtest/allowlist.txt#L158-L425Moreover, we have to always tell about this problem to new contributors on review :(
That's why I propose to special case this as we do with other
property
-likes.I've tested locally and it works perfectly. I don't want to complicate the CI with
django
installation and special tests. So, I added# pragma: no cover
to indicate that it is not tested.