* Fix type of <fieldname>_id when using ForeignKey(to_field=)
Previously mypy_django_plugin would always use the field type of target
model's primary key, but `to_field` can refer to a different field type.
* Fixes
* More fixes
This fixes the CI starting occur on #1086 and following PRs due to the release
of Django 4.1 (https://docs.djangoproject.com/en/4.1/releases/4.1/) which
shipped the change
# Even if this relation is not to pk, we require still pk value.
# The wish is that the instance has been already saved to DB,
# although having a pk value isn't a guarantee of that.
if self.instance.pk is None:
raise ValueError(
f"{instance.__class__.__name__!r} instance needs to have a primary "
f"key value before this relationship can be used."
)
in https://github.com/django/django/pull/15318.
* Improve typing for unresolved managers
This changes the logic when encountering an unresolvable manager class.
Instead of adding it as a `Manager` we create a subclass of `Manager`
that has `fallback_to_any=True` set. Similarly a `QuerySet` class is
created that also has fallbacks to `Any`. This allows calling custom
methods on the manager and querysets without getting type errors.
* Fix manager created and improve a test
* Fix row type of FallbackQuerySet
Because this inherits from _QuerySet, not QuerySet, it needs to have two
parameters
* Add support for inline from_queryset in model classes
This adds support for calling <Manager>.from_queryset(<QuerySet>)()
inline in models, for example like this:
class MyModel(models.Model):
objects = MyManager.from_queryset(MyQuerySet)()
This is done by inspecting the class body in the transform_class_hook
* Fix missing methods on copied manager
* Add test and other minor tweaks
* Always create manager at module level
When the manager is added at the class level, which happened when it was
created inline in the model body, it's not possible to retrieve the
manager again based on fullname. That lead to problems with inheritance
and the default manager.
If a django model has a Manager class that cannot be resolved statically
(if it is generated in a way where we cannot import it, like `objects =
my_manager_factory()`), we fallback to the default related manager, so
you at least get a base level of working type checking.
- Updates test_model_field_classes_from_existing_locations to account
for the behaviour change in https://github.com/python/mypy/pull/12663
- Bumps the version of django-stubs for a new release
* Bump mypy to 0.95x
* Remove the * for inferred types
There was an upstream change (https://github.com/python/mypy/pull/12459)
to remove * from inferred types in the reveal_type output.
As we are asserting the * to exist, all the test cases are now failing
on the 0.950 release. Removing the expected * to mirror the upstream
behaviour change should resolve the test failures.
* Refactor to more easily support additional config options
* Notify when Manager.from_queryset happens inside model class body
- A warning will be emitted whenever `Manager.from_queryset` happens
inside of a model class body
* Resolve generated default manager types before final iteration
A default manager on a model should always exist, eventually. Although,
we extend to look through dynamically generated managers on each
iteration instead of deferring until the final iteration.
Instead of copying methods over from a QuerySet passed to a basemanager
when invoking '<BaseManager>.from_queryset', any QuerySet methods are
declared as attributes on the manager.
This allows us to properly lookup any QuerySet method types via a
'get_attribute_hook' and will thus remove disorienting phantom errors
occuring from mypy trying to resolve types only existing in the module
where the _original_ (and real) queryset method was declared.
* Add failing test for relation to model inheriting `objects`
Fails with:
```
pytest_mypy_plugins.utils.TypecheckAssertionError: Invalid output:
Expected:
main:2: note: Revealed type is "myapp.models.MyUser*"
main:3: note: Revealed type is "myapp.models.MyUser*"
<45 (diff)
<45 (diff)
Actual:
main:2: note: Revealed type is "myapp.models.MyUser*"
main:3: note: Revealed type is "myapp.models.MyUser*"
main:6: error: "MyUser" has no attribute "book_set" (diff)
main:6: note: Revealed type is "Any" (diff)
main:7: error: "MyUser" has no attribute "article_set" (diff)
main:7: note: Revealed type is "Any" (diff)
```
* Make AddRelatedManagers look for "objects" on parent model
Previously, AddRelatedManagers would fail if a related model had inherited
its `objects` field from a parent class. This would result in missing
relation attributes. This is fixed by using `get()` instead of `names`;
the former searches the MRO for the symbol, whereas the latter only looks
for symbols declared directly on the class.
This addresses an obscure crash we're getting when defining a GenericForeignKey
subclass on a model.
Not sure how this slipped through type checking since
`helpers.lookup_class_typeinfo -> Optional[TypeInfo]` while
`.get_private_descriptor_type(type_info: TypeInfo)` so this should be a clear
type violation.
Prior to this change, ManyToManyField was declared as being generic in
_ST and _GT, but also used the _T Typevar in its __init__ signature.
This caused mypy to add _T to the variables it was generic in when used
as an alias.
The symptom of this problem was that mypy would show an error with the
message "Type application has too few types (3 expected)" where a
ManyToManyField alias was declared, but adding an extra argument would
fail because the type only takes two arguments.
This change brings the signature of ManyToManyField in line with
ForeignKey and OneToOneField.
