Upgrading to mypy 0.770 and Django-stubs 1.5, breaks mypy_django_plugin

[piyushpyoaknorth]

Bug report

Upgrading mypy and Django-stubs breaks the mypy_django_plugin

What's wrong

• I did poetry lock in my module
• This updated the versions of my dependencies
• This breaks the type checks that I do using mypy .. It works without doing these updates

How is that should be

This should not break my mypy . typechecks

System information

• OS: linux
• python version: 3.7.4
• django version: 3.0.4
• mypy version: 0.770
• django-stubs version: 1.5

[sobolevn]

Can you please post output of mypy . --show-traceback?

[piyushpyoaknorth]

...files with line numbers...
one/such/file error: INTERNAL ERROR: maximum semantic analysis iteration count reached
Found 1 error in 1 file (checked 1427 source files)

It shows a long list of internal files

[bsod90]

I'm seeing a similar behaviour in my project too:

+ mypy --no-incremental --show-traceback --config-file mypy.ini .

Unable to find node IP

./slackbot/models.py:105: error: INTERNAL ERROR -- Please try using mypy master on Github:

https://mypy.rtfd.io/en/latest/common_issues.html#using-a-development-mypy-build

Please report a bug at https://github.com/python/mypy/issues

version: 0.770

Traceback (most recent call last):

  File "mypy/semanal.py", line 4679, in accept

  File "mypy/nodes.py", line 939, in accept

  File "mypy/semanal.py", line 1001, in visit_class_def

  File "mypy/semanal.py", line 1078, in analyze_class

  File "mypy/semanal.py", line 1087, in analyze_class_body_common

  File "mypy/semanal.py", line 1147, in apply_class_plugin_hooks

  File "/usr/local/lib/python3.7/site-packages/mypy_django_plugin/main.py", line 37, in transform_model_class

    process_model_class(ctx, django_context)

  File "/usr/local/lib/python3.7/site-packages/mypy_django_plugin/transformers/models.py", line 357, in process_model_class

    initializer_cls(ctx, django_context).run()

  File "/usr/local/lib/python3.7/site-packages/mypy_django_plugin/transformers/models.py", line 71, in run

    self.run_with_model_cls(model_cls)

  File "/usr/local/lib/python3.7/site-packages/mypy_django_plugin/transformers/models.py", line 231, in run_with_model_cls

    base_manager_info=manager_info)

  File "/usr/local/lib/python3.7/site-packages/mypy_django_plugin/transformers/models.py", line 186, in create_new_model_parametrized_manager

    method_node=sym.node)

  File "/usr/local/lib/python3.7/site-packages/mypy_django_plugin/lib/helpers.py", line 355, in copy_method_to_another_class

    assert bound_arg_type is not None

AssertionError: 

./slackbot/models.py:105: : note: use --pdb to drop into pdb

script returned exit code 2

[piyushpyoaknorth]

Hi,
Any update on this issue?

[sobolevn]

Sorry, I did have the time to dig into it. Will do in several days!

[jacebrowning]

I've confirmed that the use of from __future__ import annotations seems to trigger this issue. As mentioned on the mypy documentation:

The anal_type() API method returns None if some part of the type is not available yet due to forward references, for example.

After replacing all future type references in my code with strings (e.g. my_model: MyModel => my_model: 'MyModel'), I'm unable to trip assert bound_arg_type is not None.

---

mypy==0.750 and django-stubs==1.3.2 seem to be the newest compatible versions that work with deferred type annotations.

[eyqs]

Hi, I've managed to make a minimal reproducible example, which causes Mypy to error out with "maximum semantic analysis iteration count reached". This code does not involve from __future__ import annotations, which seems to fix a different bug that doesn't involve an infinite loop.

Most interestingly, there are no type annotations in the code! And in models.py, replacing __bool__(self) with __add__(self, other), __sub__(self, other), etc. all cause this bug. Please let me know if there's anything else I can do to help, as this is blocking our team from using the Mypy plugin on our codebase, and we'd love to use it!

[eyqs]

Hi, I was wondering if anyone got a chance to look into this issue more. I upgraded to django-stubs 1.6.0 and mypy 0.782 today but unfortunately the infinite loop still exists in my minimum reproducible example.

[charettes]

@eyqs I was curious to learn if you made any progress towards identifying the cause of the issue or working around it. We've just hit it as well and getting rid of all of our usages of NamedTuple didn't seem to help unfortunately.

[mvaled]

I had this today with mypy 0.931, django-stubs 1.9.0, django-stubs-ext 0.3.1, djangorestframework-stubs 1.4.0. In my case removing the usage of a NamedTuple did fix the issue.

[flaeppe]

I think this should be closed via #1169. As it changed how reparametrization works for managers and removed the misbehaving copy_method_to_another_class, which is part of the traceback here.

Could always be reopened with a reproduction case.