Order-dependent errors in class variable type checks

[kaiw]

Apologies for the apparently-convoluted test case. I've found it to be surprisingly fragile.

class InitiallyUnowned:
    ...


class Bin("Widget"):
    ...


class Dialog("Window"):
    ...


class FontSelectionDialog("Dialog"):
    parent_instance = ...  # type: "Dialog"


class Widget("InitiallyUnowned"):
    parent_instance = ...  # type: "InitiallyUnowned"


class Window("Bin"):
    ...

which, when type-checking the stubs themselves gives:
sample.pyi:16: error: Incompatible types in assignment (expression has type "Dialog", base class "Widget" defined the type as "InitiallyUnowned")

The error appears to be highly order- and hierarchy-dependent.
If Dialog is declared after FontSelectionDialog, the bug goes away.
If Dialog subclasses Bin instead of Window, the bug goes away.
If Window subclasses Widget instead of Bin, the bug goes away.

It's probably worth mentioning that these are auto-generated stubs for GTK+/GObject introspection classes, so just manually adjusting ordering, etc. isn't really a good solution.

What is the behavior/output you expect?

No error.

What are the versions of mypy and Python you are using?

Python 3.6.7, mypy 0.650

Do you see the same issue after installing mypy from Git master?

Yes.

What are the mypy flags you are using? (For example --strict-optional)

No flags. This is just type-checking the stubs themselves.

[ilevkivskyi]

My guess is this is cause by problems with MRO calculation, so the upcoming semantic analyzer refactoring should fix this.

As a workaround, you can always topologically sort your classes, since Python classes always form a DAG w.r.t. inheritance.

(Also you don't need to use quotes and type comment syntax in stubs)

[kaiw]

As a workaround, you can always topologically sort your classes, since Python classes always form a DAG w.r.t. inheritance.

Thanks for the suggestion! That does work around the issue just fine.

(Also you don't need to use quotes and type comment syntax in stubs)

I think I could have guessed this for the quoted syntax, but for type comment syntax I assumed that this was Python version dependent. If not, it would be nice to have that noted in the stubs format documentation somewhere. Maybe it's there already and I just missed it.

[genodeftest]

Shouldn't this issue be gone with python3.7's postponed evaluation of type annotations?

[AlexWaygood]

The false-positive error is no longer reproducible on mypy 0.720+