Questions on type narrowing

[gjeusel]

Hey there,

I stumbled across some pyright type narrowing errors and was a bit surprised.
I started reading the type-narrowing section of the doc, and those cases were not mentioned.

I'm in dire need of some enlightenment.

Infos:

• Pyright: 1.1.257
• Python: 3.10.5

Inline condition

condition = "some-str"
narrowing = "" if condition else 1

reveal_type(narrowing)
# From Pyright: Type of "narrowing" is "Literal[1, '']"
# From runing: Runtime type is 'str'
# From Mypy: Revealed type is "builtins.object"

condition = "some-str"  # same typing result with: [0, 1, True, False, object()]
narrowing = "" if condition is not None else 1

reveal_type(narrowing)
# From Pyright: Type of "narrowing" is "Literal[1, '']"
# From runing: Runtime type is 'str'
# From Mypy: Revealed type is "builtins.str"

condition = "some-str"  # same typing result with: [0, 1, True, False, object()]
narrowing = "" if bool(condition) else 1

reveal_type(narrowing)
# From Pyright: Type of "narrowing" is "Literal[1, '']"
# From runing: Runtime type is 'str'
# From Mypy: Revealed type is "builtins.object"

Note: same typing result with condition being one of: [0, 1, True, False, object()]

all - any on sequences

import dataclasses

@dataclasses.dataclass
class Config:
    token: str | None = None


cfg = Config(token="secret")


if all((cfg.token,)):
    reveal_type(cfg.token)
    # From Pyright: Type of "cfg.token" is "str | None"
    # From runing: Runtime type is 'str'

The question

Is it a bug in pyright ?

[erictraut]

All of your examples are working as designed, so I don't see any bugs here. Is there a particular case that you're wondering about?

[gjeusel]

Well, let's focus on this one:

narrowing = "" if True else 1
reveal_type(narrowing)  # Type of "narrowing" is "Literal[1, '']"

I don't understand why we can't narrow the type of the variable to Literal[''] or at least str ?

[erictraut]

What you're talking about here isn't type narrowing.

Type narrowing applies to an expression whose type is initially wider but is determined to become "narrower" through either assignment or through a conditional test. Take the following example, where x has a declared type of int | None. The x is not None conditional check narrows the type of the expression x to the narrower type int (in the positive "if" case) or None (in the negative "else" case).

def foo(x: int | None):
    if x is not None:
        reveal_type(x) # int
    else:
        reveal_type(x) # None

In your example, there is no expression whose type could be narrowed. From the context of your question, I presume that you're asking about type inference, not type narrowing.

The variable narrowing has no declared type, so its type must be inferred from its assigned value. In this case, it is assigned a value from a ternary operator (an expression of the form x if cond else y). Pyright infers the type of a ternary operator by combining the type of the left-hand operand and right-hand operand. In this case, the left-hand type is Literal[''], and the right-hand type is Literal[1], so the resulting inferred type is Literal[1, ''].

Pyright's inference logic for a ternary operator doesn't currently take into account cases where the condition can be statically proven to be falsy or truthy. That would be possible to add, but I don't know why someone would write a ternary expression where the answer is statically known. If you can provide a compelling use case for this, I would consider adding this additional logic.

[gjeusel]

Thank you very much for the explanation !

I understand why the assignment from a ternary operator is called type inference.
And yes indeed, I can't see any compelling case to write something like this.

Switching to the "all - any on sequences", there is a practical use case for this one.

@dataclasses.dataclass
class Config:
    token: str | None = None


cfg = Config(token="secret")


if all((cfg.token,)):
    reveal_type(cfg.token)  # str | None   # expected str
else:
    reveal_type(cfg.token)  # str | None

Altough:

if cfg.token:
    reveal_type(cfg.token)  # str
else:
    reveal_type(cfg.token)  # str | None

is working like a charm, let's assume we got some other config variables required to be filled to instantiate some client.

What prevents pyright from narrowing the cfg.token type ?

[erictraut]

Pyright supports a number of built-in type guards. For a complete list, see this documentation. Each type guard pattern requires special logic.

All type guards that pyright supports operate on simple name expressions (e.g. foo), member access expressions (e.g. foo.bar), or certain forms of index expressions (e.g. foo[1]). It does not act on more complex expressions like (cfg.token, ).

Also, from the perspective of a type checker, all is simply a call to a function. Pyright has no special knowledge of what all happens to do internally. The only information it can go on is based on the type information associated with all:

def all(__iterable: Iterable[object]) -> bool: ...

Pyright supports user-defined type guards as described in PEP 647. If pyright doesn't support a type narrowing pattern that you would like to use, you can use TypeGuard to write your own.

[gjeusel]

Thank you very much for the explanations and your time !