False positive used-before-assignment when assignment can be an import

[mthuurne]

Steps to reproduce

Run pylint on the following code:

from typing import TYPE_CHECKING

if TYPE_CHECKING:
    from collections import Counter
else:
    Counter = object

def tick(c: Counter, name: str) -> None:
    c[name] += 1

While this example is rather pointless, I use similar constructs a lot when I have to import a name only for the purpose of type checking. It helps avoid import cycles between modules.

Current behavior

pylint reports on the def tick line:

E0601: Using variable 'Counter' before assignment (used-before-assignment)

Expected behavior

No errors are reported, since Counter is guaranteed to be defined.

pylint --version output

pylint 2.4.0
astroid 2.3.0
Python 3.7.2 (default, Feb 26 2019, 13:02:33)
[GCC 7.3.1 20180323 [gcc-7-branch revision 258812]]

[mthuurne]

That's quick. Thanks!

[mthuurne]

It seems the fix in 2.4.1 fixes the case where one type is imported inside a type guard, but when multiple types are imported, there is still an error reported for every type except the first.

For this test case:

from typing import TYPE_CHECKING

if TYPE_CHECKING:
    from collections import Counter
    from collections import OrderedDict
else:
    Counter = object
    OrderedDict = object

def tick(c: Counter, deltas: OrderedDict) -> None:
    for name, delta in deltas.items():
        c[name] += delta

pylint reports:

E0601: Using variable 'OrderedDict' before assignment (used-before-assignment)

[Deimos]

I'm still seeing this false positive on a similar case. For me, it's a workaround because mypy doesn't deal with SQLAlchemy's hybrid_property decorator correctly, so I do this:

if TYPE_CHECKING:
    from builtins import property as hybrid_property
else:
    from sqlalchemy.ext.hybrid import hybrid_property

This makes it so that mypy treats @hybrid_property as @property and understands the getter/setter methods. However, it's causing a used-before-assignment error in pylint 2.4.4.

[snejus]

Same issue here, pylint 2.5.2:

from typing import TYPE_CHECKING, Type

if TYPE_CHECKING:
    from django.db.models import Model

def run(sender: Type[Model]):

[mthuurne]

Same issue here, pylint 2.5.2:

from typing import TYPE_CHECKING, Type

if TYPE_CHECKING:
    from django.db.models import Model

def run(sender: Type[Model]):

I think in that example pylint is correct to report an error, since that will lead to a runtime error when executed and Model is undefined when the def statement runs.

[snejus]

You are entirely correct - sorry for making waves :)

[wieczorek1990]

Use:

from __future__ import annotations