Match-case on type() is not well interpreted

[Hibou57]

Environment

• Python version: 3.12.3
• PyRight version: 1.1.411
• PyRight configuration: pyrightconfig.json

Describe the bug

Discriminating based on the type of an object, using a match-case statement, seems erroneously interpreted by PyRight. It complains about lack of cases coverage, erroneously, and additionally suggest terms to add case statements which are syntactically invalid for Python.

PyRight is very clean and useful, but I feel disappointed with this issue, because case coverage checking is as much important as type checking (like in SML). Can still type-check adding an assert isintance(...) at the start of each case branch, but ensuring coverage is sadly missing and it's really important.

Code or Screenshots

There are explanations in the comments.

Note to other people: the example below only matches exact classes (the real case is with some NamedTuple classes). If inst was an instance of a derived class of B, it would not work (would print nothing). I don’t know if there exist a way to express the same with the idea of matching derived class and with the benefit of cases coverage check. There is isinstance but it cannot be used in this match expression.

import builtins

class Base:
    pass

class A(Base):
    pass

class B(Base):
    pass

class C(Base):
    pass

# Add classes in a kind of name-space, so that the cases in the match, are not
# taken to be variable names. Without this, the case statements don’t mean what
# is intended. The bug is not here, this to explain to people who try to
# discover and learn things.
class NS:
    A = A
    B = B
    C = C

inst: Base = B()

match type(inst):
    case NS.A:
        print("A")
    case NS.B:
        print("B")
    case NS.C:
        print("C")

# It prints "B", as expected, so it works, but PyRight complains about this:
# > error: Cases within match statement do not exhaustively handle all values
# > Unhandled type: "type[B]"

# Additionally, the suggestion is misleading, because using `type[...]` yields
# a syntax error. Please, un-comment the below if you want to test it.
#
#  match type(inst):
#      case builtins.type[NS.A]:
#          print("A")
#      case builtins.type[NS.B]:
#          print("B")
#      case builtins.type[NS.C]:
#          print("C")

[Hibou57]

The wrong error message can be hidden with something looking like this:

match type(...):  # pyright: ignore[reportMatchNotExhaustive]

But it only hides the message, it does not give the correct check.

[Hibou57]

if-elif with isinstance can be used as a workaround, but the issue is in the readability, because the last branch is an else with no explicit type indication, and that does not help understanding when reading days or months later (yes, there are comments, but comments are not checks in Python) . If it ends with an elif instead of an else, PyRight rightfully complains this check is not required. There are many discriminating where match-case is cleaner than if-elif, even if it adds a level of indentation.