Reuse functools.cached_property definition instead of defining our own

[intgr]

I have made things!

This was motivated by my comments at #1761 (review).

Mypy has special handling for functools.cached_property, making it compatible with classvars and the @property decorator (mypy-play example). But this handling did not extend to our django.utils.functional.cached_property.

By simply re-exporting functools.cached_property, we can piggyback on the already existing infrastructure in typeshed/mypy.

Note that typeshed did not define functools.cached_property on Python 3.7 and older. So this will break for users of older Python versions. But I think that's fine since we advertise 3.8 as the minimal Python version.

Ping @flaeppe @UnknownPlatypus, any reservations about this approach here?

• TODO: Would be useful to have a test for property/cached_property compatbility

Related issues

• Require 1 callable argument for @cached_property #1766
• Update @property attributes to @cached_property part 1 #1761
• Update @property attributes to @cached_property part 2 #1768
• Update Expression classes output_field to @cached_property or ClassVar and improve type #1769

[UnknownPlatypus]

@intgr , I like this idea and was experimenting a bit with it yesterday for #1761 and related pr's.

I do think it's a good thing because we want the special mypy behavior, and doing this is the easiest way to get there. Django will also use functools.cached_property directly some day.

---

That being said, this PR breaks the stubtest.sh script.

Firstly with errors directly linked to django.utils.functional.cached_property we should just ignore.

django.utils.functional.cached_property errors

error: django.utils.functional.cached_property.__class_getitem__ is not present at runtime
Stub: in file /home/thibaut/workspace/django-stubs/django-stubs/utils/functional.pyi:196
def (cls: Type[functools.cached_property[_T`1]], item: Any) -> types.GenericAlias
Runtime:
MISSING

error: django.utils.functional.cached_property.__init__ is inconsistent, stub does not have argument "name"
Stub: in file /home/thibaut/workspace/django-stubs/django-stubs/utils/functional.pyi:187
def (self: functools.cached_property[_T`1], func: def (Any) -> _T`1)
Runtime: in file /home/thibaut/workspace/django-stubs/.venv/lib/python3.11/site-packages/django/utils/functional.py:26
def (self, func, name=None)

error: django.utils.functional.cached_property.__set__ is not present at runtime
Stub: in file /home/thibaut/workspace/django-stubs/django-stubs/utils/functional.pyi:194
def (self: functools.cached_property[_T`1], instance: builtins.object, value: _T`1)
Runtime:
MISSING

error: django.utils.functional.cached_property.name is not present in stub
Stub: in file /home/thibaut/workspace/django-stubs/django-stubs/utils/functional.pyi
MISSING
Runtime:
None

Secondly because every cached_property we declared in the stub defer in type from runtime (because we now declare them as functools.cached_property in stubs but they are actually django.utils.functional.cached_property at runtime.)

sample "cannot reconcile @Property on stub with runtime object" errors

error: django.urls.resolvers.URLResolver.url_patterns is inconsistent, cannot reconcile @property on stub with runtime object
Stub: in file /home/thibaut/workspace/django-stubs/django-stubs/urls/resolvers.pyi:129
def (self: django.urls.resolvers.URLResolver) -> builtins.list[Union[django.urls.resolvers.URLPattern, django.urls.resolvers.URLResolver]]
Runtime:
<django.utils.functional.cached_property object at 0x7f4e75b674d0>

error: django.urls.resolvers.URLResolver.urlconf_module is inconsistent, cannot reconcile @property on stub with runtime object
Stub: in file /home/thibaut/workspace/django-stubs/django-stubs/urls/resolvers.pyi:127
def (self: django.urls.resolvers.URLResolver) -> Union[types.ModuleType, None, typing.Sequence[Union[django.urls.resolvers.URLPattern, django.urls.resolvers.URLResolver]]]
Runtime:
<django.utils.functional.cached_property object at 0x7f4e75b67490>

error: django.utils.connection.BaseConnectionHandler.settings is inconsistent, cannot reconcile @property on stub with runtime object
Stub: in file /home/thibaut/workspace/django-stubs/django-stubs/utils/connection.pyi:22
def (self: django.utils.connection.BaseConnectionHandler[_T`1]) -> builtins.dict[builtins.str, Any]
Runtime:
<django.utils.functional.cached_property object at 0x7f4e75f0c2d0>

Both "issues" are not really a problem I think, if we go down this road, this is normal to have them. We just need to add some entries to the allowlist.txt file. Adding --generate-allowlist to the stubtest script should give you that.

Finally, I noticed that stubtest now don't raise errors for cases where runtime is a cached_property but stubs use a property. This might make it a bit more difficult to stay sync but since it mostly don't change anything, typing wise, it's probably ok.

TODO: Would be useful to have a test for property/cached_property compatbility

About that, you might want to extend the test that is currently failing in this MR.

[sobolevn]

I like the idea!

[flaeppe]

I also think this is what we want, piggybacking on the special treatment of functools.cached_property.

This is not a very fresh reference, but I'm gonna use it anyway: https://stackoverflow.com/a/68594071

So, if that still stands, which I think it does. We should really be more than fine, it's just unfortunate that it's difficult to get alignments with overrides..

Also, the ticket linked from SO above is relevant: https://code.djangoproject.com/ticket/30949

[intgr]

I finally found the time to fix the tests as well.

Thanks for the pointers @UnknownPlatypus

As can be seen from the test diff, functools.cached_property has somewhat different behavior in mypy (on the class it appears as a function instead of a property descriptor). But for typical code using cached_property, this is unimportant.

[flaeppe]

👍