Fixing 'Import cycle from Django settings module prevents type inference'

[intgr]

In recent versions, the mypy plugin of django-stubs has started issuing a new warning in cases where the plugin is unable to resolve the type of a setting, for example:

from django.conf import settings

print(settings.SOME_SETTING)

Causes error:

error: Import cycle from Django settings module prevents type inference for 'SOME_SETTING' [misc]

The recommended solution is to add an explicit type hint into the main settings file that is used by the django-stubs:

-SOME_SETTING = func_returning_int()
+SOME_SETTING: int = func_returning_int()

(thanks to @flaeppe in #1163 (comment))

[flaeppe]

I'm honestly unsure why this error is emitted by the plugin in the first place.

Deserves to be investigated if it's a remnant of an old mypy crash fix, or if it leads to any other issue(s).

I'm suspecting that we might be able to remove the code yielding the error

[intgr]

I opened a PR with a test case that demonstrates this in practice. #2098

[shmulvad]

I'm seeing this error as well after upgrading to 5.0.0, in some cases for extremely obvious variables where it should be trivial to infer the type. For example:

# settings.py
DEFAULT_FROM_EMAIL = f'Company Name <[email protected]>'

$ mypy .
# error: Import cycle from Django settings module prevents type inference for 'DEFAULT_FROM_EMAIL'  [misc]

If I explicitly add the type hint, it works

# settings.py
DEFAULT_FROM_EMAIL: str = f'Company Name <[email protected]>'

$ mypy .
# Success: no issues found in [x] source files

Of course, I can make the error go away by adding the type hint, but I'd prefer to not have to explicitly add types for all variables in my settings.py that are used elsewhere and can easily be inferred.

[intgr]

Indeed, "e517a1fb2bcdad20cc50930c43b285cb0650f292 is the first bad commit", it comes from PR #2024

And reverting that commit removes the mypy errors I was experiencing.

[flaeppe]

Interesting, perhaps we should change the priority only for django.conf.settings?

[flaeppe]

I even think it's reasonable to use PRI_HIGH for django.conf.settings since that's essentially a proxy for importing the real settings module.

[flaeppe]

I just tried it out and realised that increasing to PRI_HIGH the test case added in #2098 breaks. The error is not emitted any longer.

[intgr]

I opened a PR as well. Anyway let's continue the discussion there.