Match statement with None pattern does not induce type narrowing

[mjpieters]

Environment data

• Language Server version: 2022.9.20
• OS and version: darwin arm64
• Python version (and distribution if applicable, e.g. Anaconda): 3.10.6
• python.analysis.indexing: null
• python.analysis.typeCheckingMode: basic

Code Snippet

Consider the following structural matching example:

from enum import Enum

class Spam(Enum):
    state1 = 0
    state2 = 1

def foo(bar: str | None, spam: Spam) -> str:
    match bar, spam:
        case None, _:
            result = "absent"
        case b, Spam.state1:
            result = f"state 1: {b.upper()}"
        case b, Spam.state2:
            result = f"state 2: {b.upper()}"
    return result

Pylance reports that b is of type str | None and so "upper" is not a known member of "None" is reported. However, the case None, _: pattern should be seen as an assertion that b is not None for the other branches.

The issue can be mitigated by adding if b guards:

    match bar, spam:
        case None, _:
            result = "absent"
        case b, Spam.state1 if b:
            result = f"state 1: {b.upper()}"
        case b, Spam.state2 if b:
            result = f"state 2: {b.upper()}"

I'm not sure if this is directly related, but Pylance also reports that result is possibly Unbound; the branches of the match statement are exhaustive as all combinations of bar and spam are covered (either bar is None and it doesn't matter what value spam has, or bar is a string and all possible values for spam are covered).

This issue can be mitigated by adding a wildcard case with raise or assert False:

    match bar, spam:
        case None, _:
            result = "absent"
        case b, Spam.state1:
            result = f"state 1: {b.upper()}"
        case b, Spam.state2:
            result = f"state 2: {b.upper()}"
        case _:
            # never reached
            raise NotImplementedError

[erictraut]

This is "as designed" behavior. Type narrowing cannot be applied here because the subject expression (the expression you are matching against) is a tuple expression, and type narrowing does not apply to tuples. It applies only to simple names, member access expressions, and simple index expressions.

If you want type narrowing to work (in pylance or other type checkers like mypy), you will need to refactor your code so you match against an expression type where type narrowing is supported. Here's one approach.

def foo(bar: str | None, spam: Spam) -> str:
    match bar:
        case None:
            result = "absent"
        case b:
            match spam:
                case Spam.state1:
                    result = f"state 1: {b.upper()}"
                case Spam.state2:
                    result = f"state 2: {b.upper()}"
    return result

[erictraut]

Actually, my previous explanation was a bit misleading. The problem is not that the subject expression form is not supported. The issue is that the type checker doesn't perform narrowing on individual elements of a tuple. The initial type of the subject expression is tuple[str | None, Spam]. The first case could theoretically narrow this to tuple[str, Spam] in the fall-through case, but pylance (and mypy) do not perform type narrowing of this sort. This could be added, but it would be quite complex. It's something we could consider adding in the future if there is sufficient demand. I'm not aware of any other type checkers or compilers in other languages that implement this type of narrowing. For example, TypeScript doesn't do this.

[debonte]

It's something we could consider adding in the future if there is sufficient demand.

@judej, convert to enhancement discussion?

[judej]

Moving this issue to discussion as an enhancement request for comments and upvotes.

[mjpieters]

Right, I had indeed not interpreted this as matching a tuple against each branch.

I can see that extending type narrowing to individual tuple elements might be a slippery slope (e.g. how should foo: tuple[tuple[tuple[str | None], Spam]], then if foo[0][0][0] is not None: be treated?), so I'd understand it if type narrowing is explicitly limited to top-level types only.