False warnings and crash with dynamic class in match statement

[ljodal]

Crash Report

Using a dynamically created class in a match statement produces a warning about it not being a type. If the match also has *rest clause mypy crashes.

Traceback

reproducer.py:15: error: Expected type in class pattern; found "Type[reproducer.Example]"
reproducer.py:14: error: INTERNAL ERROR -- Please try using mypy master on GitHub:
https://mypy.readthedocs.io/en/stable/common_issues.html#using-a-development-mypy-build
Please report a bug at https://github.com/python/mypy/issues
version: 0.960
Traceback (most recent call last):
  File "mypy/checker.py", line 431, in accept
  File "mypy/nodes.py", line 1415, in accept
  File "mypy/checker.py", line 4155, in visit_match_stmt
  File "mypy/checkpattern.py", line 104, in accept
  File "mypy/patterns.py", line 87, in accept
  File "mypy/checkpattern.py", line 261, in visit_sequence_pattern
  File "mypy/checkpattern.py", line 366, in expand_starred_pattern_types
IndexError: list index out of range
reproducer.py:14: : note: use --pdb to drop into pdb

To Reproduce

The following self-contained example demonstrates both the false warning and the crash. At runtime it works fine and prints SubClass with value: my value

# reproducer.py
class Example:
    __match_args__ = ("_value",)

    def __init__(self, value: str) -> None:
        self._value = value

def example(name: str) -> type[Example]:
    return type(name, (Example, ), {})

SubClass = example("SubClass")

t = [SubClass("my value"), SubClass("Other value")]

match t:
    case [SubClass(value), *rest]:
        print(f"SubClass with value: {value}")

Your Environment

• Mypy version used: 0.960
• Mypy command-line flags: None
• Mypy configuration options from mypy.ini (and other config files): None
• Python version used: 3.10.4
• Operating system and version: macOS 12.3.1

[ljodal]

In case anyone else hits this: It's possible to work around it with a plugin using the get_dynamic_class_hook callback. The plugin just have to create the types for mypy, so it properly understands that it's classes.

E.g. I have a working plugin here:
https://github.com/ljodal/hap/blob/3a9bceb3f3774c4cb64f1d43eb830975a77d4ea6/hap/mypy.py#L27-L52

[dosisod]

I think I have found some similar behavior, though I don't know if I should make a separate issue for it. The following program fails type checking:

def some_func() -> None:
    f = str

    match "123":
        case f(x):
            print(f"matched '{x}'")

some_func()

Type checking:

$ mypy main.py
main.py:5: error: Expected type in class pattern; found "Overload(def (object: builtins.object =) -> builtins.str, def (object: Union[builtins.bytes, builtins.bytearray, builtins.memoryview, array.array[Any], mmap.mmap, ctypes._CData, pickle.PickleBuffer], encoding: builtins.str =, errors: builtins.str =) -> builtins.str)"
Found 1 error in 1 file (checked 1 source file)

Yet the same program (with surrounding function removed) passes type checking:

f = str

match "123":
    case f(x):
        print(f"matched '{x}'")

$ mypy main.py
Success: no issues found in 1 source file

Both versions run just fine in python though:

matched '123'

[hauntsaninja]

@dosisod your thing is separate, assignments in functions aren't treated as type aliases. Maybe use an explicit PEP 613 type and see if it solves your case

[dosisod]

Hm, that does fix it, but PEP 613 (Scope Restrictions) says that type aliases should not be allowed at the function scope, but Mypy seems to allow it:

class ClassName: pass

x: TypeAlias = ClassName
def foo() -> None:
  x = ClassName
def bar() -> None:
  x: TypeAlias = ClassName  # <-- supposedly not allowed

Mypy says it looks fine (Pyright does give an error though).

Quoting from PEP 613 (emphasis is mine): "With explicit aliases, the outer assignment is still a valid type variable. Inside foo, the inner assignment should be interpreted as x: Type[ClassName]. Inside bar, the type checker should raise a clear error, communicating to the author that type aliases cannot be defined inside a function."

@hauntsaninja , should I open an issue for this? Thanks!

[hauntsaninja]

I'm not willing to make that change. It's an unnecessary and user hostile restriction (as was the restriction on class scoped aliases before we edited that out).
https://mail.python.org/archives/list/typing-sig@python.org/thread/CGOO7GPPECGMLFDUDXSSXTRADI4BXYCS/#CGOO7GPPECGMLFDUDXSSXTRADI4BXYCS

Anyway, all of this is off-topic on this issue.