Skip to content

Expand override manager create test + move to assert_type - #3559

Merged
UnknownPlatypus merged 2 commits into
typeddjango:masterfrom
UnknownPlatypus:expand-override_manager_create
Aug 4, 2026
Merged

UnknownPlatypus merged 2 commits into
typeddjango:masterfrom
UnknownPlatypus:expand-override_manager_create

Conversation

@UnknownPlatypus

Copy link
Copy Markdown
Contributor

I have made things!

Expand the coverage for maanger create overloads.
The unparametrized case exercise a bit of plugin but not the others two so I moved it to assert_type.

This also revealed that our typing of Model.objects as ClassVar[Manager[Self]] is already a bit problematic with pyright and pyrefly (see the type-ignore's). Given this exemple:

class Book(models.Model):
    objects = BookManager()
    foo = BookManager() 

I get these revealed types

┌─────────────┬───────────────┬─────────────┐
│             │ Book.objects  │  Book.foo   │
├─────────────┼───────────────┼─────────────┤
│ mypy+plugin │ BookManager   │ BookManager │
├─────────────┼───────────────┼─────────────┤
│ ty          │ BookManager   │ BookManager │
├─────────────┼───────────────┼─────────────┤
│ pyright     │ Manager[Book] │ BookManager │
├─────────────┼───────────────┼─────────────┤
│ pyrefly     │ Manager[Book] │ BookManager │
└─────────────┴───────────────┴─────────────┘

To me our declaration in the stubs should not impact regular class level assignment inference and I would expect objects to have the same type as foo. The plugin should only apply the "does not exist on abstract model" bit, the rest should be regular inference.

I'm exploring how to improve that, maybe with a descriptor in a followup pr

Related issues

Still trying to cut the bulk for #2776

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

@sobolevn sobolevn left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:(

@UnknownPlatypus
UnknownPlatypus merged commit 92aee73 into typeddjango:master Aug 4, 2026
44 checks passed
@UnknownPlatypus
UnknownPlatypus deleted the expand-override_manager_create branch August 4, 2026 08:20
crgwbr added a commit to thelabnyc/django-oscar-stubs that referenced this pull request Sep 14, 2026
django-stubs 6.1.1 dropped `objects: ClassVar[Manager[Self]]` from `Model` in
favour of a metaclass `__getattr__` fallback (typeddjango/django-stubs#3559).
Type checkers still resolve `Model.objects` through it, but stubtest only
compares declared attributes, so all 63 models that rely on the inherited
default started reporting `objects is not present in stub`.

Allowlist the attribute rather than declaring it per model: an explicit
`ClassVar[Manager[X]]` in the stubs would shadow the manager type django-stubs'
plugin synthesizes, which would cost downstream users their custom manager
methods. The allowlist matches by name only, so stubtest no longer verifies
any `objects` attribute, the explicit custom-manager declarations included;
manager types stay guarded by the django-stubs plugin and the mypy-plugins
suite. The regex replaces eight exact per-model entries it subsumes.

This was failing on master too, since tox resolves `django-stubs>=6.1`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants