Type admin site as DefaultAdminSite inheriting from Adminsite

[ahmedasar00]

I have made things!

Related issues

Fixes stubtest error: django.contrib.admin.site variable differs from runtime type django.contrib.admin.sites.DefaultAdminSite

AI Policy

• I have read and agree to the AI Policy, removed any "Co-Authored-By" lines attributing coding agents, and manually reviewed the final result

[UnknownPlatypus]

This one is tricky but I don't think this is a correct fix.

The LazyObject make this site behaves like an AdminSite object. You can try it yourself

>>> from django.contrib.admin.sites import site
>>> site
AdminSite(name='admin')

[ahmedasar00]

Thanks for the review! I agree it's tricky, I understand that DefaultAdminSite proxies to DefaultAdminSite via LazyObject, not through actual inheritance.!

What would be the correct approach here?

[UnknownPlatypus]

What is the stubtest error exactly ?

We probably will just have to mive this allowlist entry to the main allowlist.txt with a comment, possibly next to similar entries if there are any

[ahmedasar00]

error: django.contrib.admin.site variable differs from runtime type
django.contrib.admin.sites.DefaultAdminSite
Stub: in file django-stubs/contrib/admin/__init__.pyi:86
django.contrib.admin.sites.AdminSite
Runtime:
AdminSite(name='admin')

And the same for django.contrib.gis.admin.site.

I can update this PR to move the entry to allowlist.txt with a comment instead, if you'd prefer that approach.

[UnknownPlatypus]

My preference would be to get to the bottom of this, it's either a bug in stubtest or something wrong with how we type LazyFunc or use it here

Should it be that maybe ?

class DefaultAdminSite(AdminSite): ...
site: LazyObject[AdminSite]

but site: DefaultAdminSite will cause false positives for pretty much every attribute access that are expected on AdminSite but not present here no ?

[ahmedasar00]

Interesting finding: type(site) returns DefaultAdminSite, but site.__class__ returns AdminSite because LazyObject.__getattr__ proxies __class__ to the wrapped object. That's why isinstance(site, AdminSite) is True even though issubclass(DefaultAdminSite, AdminSite) is False.

So the issue seems to be that stubtest uses type(site) and sees DefaultAdminSite, while the stub says AdminSite. This might be a stubtest limitation, it doesn't account for LazyObject's __class__ proxying behavior.

Should I investigate how LazyObject is typed to see if there's a way to make this work properly?

[UnknownPlatypus]

So the issue seems to be that stubtest uses type(site) and sees DefaultAdminSite, while the stub says AdminSite. This might be a stubtest limitation, it doesn't account for LazyObject's class proxying behavior.

@sobolevn Shoul we do something about it ? Is it a stubtest limitation with thes proxy objects ?