Errors on multi-variable assignments of types

[MrMino]

Bug Report

MyPy seems to have issues when multi-variable assignments of types to their aliases are involved.

To Reproduce
Run mypy on the following two sources:

from typing import Any

typ_a = Any
typ_b = Any
def test1(x: typ_a, y: typ_b): pass

from typing import Any

typ_a, typ_b = Any, Any
def test2(x: typ_a, y: typ_b): pass

typ_a = typ_b = Any
def test3(x: typ_a, y: typ_b): pass

Expected Behavior
MyPy does not show any errors for any of the function's signatures, since they are all essentially the same.

Actual Behavior
MyPy shows the following errors for test2 and test3:

repro2.py:4: error: Variable "repro2.typ_a" is not valid as a type
repro2.py:4: note: See https://mypy.readthedocs.io/en/latest/common_issues.html#variables-vs-type-aliases
repro2.py:4: error: Variable "repro2.typ_b" is not valid as a type
repro2.py:7: error: Variable "repro2.typ_a" is not valid as a type
repro2.py:7: note: See https://mypy.readthedocs.io/en/latest/common_issues.html#variables-vs-type-aliases
repro2.py:7: error: Variable "repro2.typ_b" is not valid as a type
Found 4 errors in 1 file (checked 1 source file)

Confusingly, if one merges the two source files, no errors are shown.

Your Environment

• Mypy version used: 0.800
• Mypy command-line flags:
• Mypy configuration options from mypy.ini (and other config files):
• Python version used: 3.9.1
• Operating system and version: Ubuntu 20.04

[JelleZijlstra]

This is because only the x = y form is recognized as creating a type alias. https://www.python.org/dev/peps/pep-0613/ is an attempt to make this behavior more explicit. We could document this better in https://mypy.readthedocs.io/en/stable/kinds_of_types.html#type-aliases, so keeping this open as a documentation issue.

[agryman]

@JelleZijlstra I'd appreciate your insight on the validity of a chained assignment of type aliases, e.g.

A = B = int

Are you saying that this pattern is outside the scope of PEP 484, or that it is simply a limitation of the current implementation of mypy? As I mentioned in #12995 this pattern is present in SymPy:

Matrix = MutableMatrix = MutableDenseMatrix

Python does handle it correctly. It treats Matrix as a class.

>>> from sympy import Matrix
>>> type(Matrix)
<class 'type'>

Of course, the fact the it "works" doesn't imply that PEP 484 specifies it. PEP 484 contains the following statement in
https://peps.python.org/pep-0484/#type-aliases

"Type aliases are defined by simple variable assignments:"

Read literally one could interpret that as "simple and only simple". It that the mypy reading?

[erictraut]

Most programming languages include a keyword to distinguish type alias declarations from normal variable assignments. Python does not contain such a keyword (at least not in current versions of the language — there are active proposals to add such a keyword). As such, type checkers need to use clues to differentiate between type alias declarations and variable assignments. Mypy — along with pyright and pyre — all make the assumption that type aliases will use a single assignment rather than a chained assignment. If your intent is to define a type alias, use a single assignment. If you want to define two type aliases, use separate statements. It's that simple.

[JelleZijlstra]

Thanks @erictraut, I was planning to ping you for your opinion :)

In summary, both forms discussed in the OP (A, B = int, str and A = B = int) are invalid as type aliases, and we're unlikely to add support.

[agryman]

@erictraut Thanks. I agree it's simple. My problem was trying to pursuade the SymPy team. I think it's clear that only simple assignments are valid so I'll go ahead and submit a PR to SymPy.

fyi, TypeAlias is part of Python 3.10: https://docs.python.org/3/library/typing.html#typing.TypeAlias

[oscarbenjamin]

To be clear the line of code we are talking about in SymPy originated in 2012 and predates mypy or any of the type-checking PEPs. It was never intended to be a "type alias" in the specific sense detailed in the PEPs. It is valid Python code though that works just as well now as it did then.

The general reservation from SymPy's side is that it shouldn't be necessary to change valid code to work around the deficiencies of Python's type checking ecosystem: a type checker for Python should be able to handle ordinary Python code.

[erictraut]

a type checker for Python should be able to handle ordinary Python code

That's not the right way to look at it. There are limitless examples of code that runs without generating an exception at runtime but does not pass static type checking. The goal of static typing is to provide Python developers with tools to catch bugs before running the code and benefit from edit-time conveniences like completion suggestions. You are free to ignore static typing if you find that it doesn't provide sufficient value, but if you (or the consumers of your library) want to take advantage of static typing, then you need to work within with the tools and the type system. That sometimes involves some (typically minor) accommodations.

[oscarbenjamin]

You are free to ignore static typing if you find that it doesn't provide sufficient value

That's not really the case because we have people like @agryman who want to use mypy with their code that uses SymPy. The problem here was triggered by adding the py.typed file (sympy/sympy#22337). I am tempted to just remove that file...

That sometimes involves some (typically minor) accommodations.

Having personally done the initial work to make the SymPy codebase pass under mypy without errors I can say that a lot of unnecessary changes were needed without even trying to add type hints (e.g. sympy/sympy#18244, sympy/sympy#20140, sympy/sympy#22212). A few minor improvements resulted from that work but so far the gain seems pretty minimal. We continue to use mypy in CI (sympy/sympy#22320) but from my perspective the only noticeable benefit of doing so is that it stops contributors from adding incorrect type hints.

[agryman]

Based on my reading of PEP 484, I think that mypy is correct as-is. The PEP says that type aliases are defined by simple assignments. I'd close this issue as "working as specified by PEP 484".

[emmatyping]

Yeah, this issue is left open to track documenting the error and explain why it happens.