attrs match type narrowing failure

[Tinche]

Bug Report

Hello Mypy friends!

While playing around with yet another proposal for sum types (typing-sig message forthcoming), I think I found a small issue with attrs and the match statement.

To Reproduce

from typing import Generic, TypeVar

from attrs import frozen
from typing_extensions import assert_never

T = TypeVar("T")


@frozen
class Some(Generic[T]):
    val: T

Expected and Actual Behavior

Now we define a function that handles it.

def takes_opt(opt: Some[int]) -> None:
    match opt:
        case Some(val):
            reveal_type(opt)  # Correct, Some[int]
            reveal_type(opt.val)  # Correct, int
            reveal_type(val)  # Incorrect, Any
            pass
        case _:
            assert_never(opt)

So I'm going to guess it's an issue with how we generate attrs __match_args__, maybe for generic types. I might try solving this myself, or it would be awesome if someone more knowledgeable could solve it first.

If I use dataclasses it works properly.

Your Environment

• Mypy version used: mypy 0.982 (compiled: yes)
• Mypy command-line flags:
• Mypy configuration options from mypy.ini (and other config files):
• Python version used: Python 3.10.6

[sobolevn]

Not directly related, but check out our Some implementation: https://returns.readthedocs.io/en/latest/pages/maybe.html

[mgedmin]

I think I stumbled upon this bug too. Given

class PrintableKey(bytes):
    __match_args__ = ('ch', )

    @property
    def ch(self) -> str:
        return self.decode('UTF-8')

now

match event:
    case PrintableKey(ch):
        reveal_type(ch)  # mypy thinks it's PrintableKey

versus

match event:
    case PrintableKey(ch=ch):
        reveal_type(ch)  # mypy correctly deduces it's str

[brianschubert]

Duplicate of #13612. This bug was fixed in #13618, which landed with v0.990.

@mgedmin Good find! That's a different bug (one that has to do with some special handling for class patterns involving builtin types). Could you please open a new issue?