Literal[True, False] and bool

[pinterior]

def f() -> Literal[True, False]:
    ...
reveal_type(f)

shows f is () -> bool, not a () -> Literal[True, False].
this merging is reasonable.

def g(a: Callable[[], Union[T, Literal[False]]]):
    v = a()
    if v:
        return v
    raise RuntimeError()

reveal_type(g(f))

but because of the merging, g(f) is inferred as bool, not Literal[True] .
how about keep Literal[True, False] as is, or defer merging to certain point?

[erictraut]

You're making a few tenuous assumptions here. You're not only assuming that Literal[True, False] won't be converted internally by a type checker to the equivalent type bool, but you're also relying on heuristics in the constraint solver. The solution of T=bool is a correct and defensible solution for the constraints provided.

It's theoretically possible to tweak the heuristics in pyright to give the results you're looking for, but changing heuristics tends to affect type checking of other code in ways that are difficult to predict. I don't think that makes sense in this case, so you'll need to find some other workaround.

[pinterior]

sure, understood.

i thought if selenium's WebDriverWait#until (has a type (WebDriver -> T | False) -> T) can eliminate False-ability of return value of WebDriver -> WebElement | bool type conditions.