Type narrowing: isinstance doesn't match cast behaviour when TypeVar has a default

[TMVector]

1. I would like type narrowing from an isinstance check on a generic type without type arguments to behave the same as using cast, as per below. Am I misunderstanding something, or would this be a useful feature request?

2. If the TypeVar doesn't have a default but it does have a bound -- is there any reason pyright couldn't infer val as of type Slice[Val] instead of `Slice[Unknown]'? I realise that question might be a bit more complex than the first!

from abc import ABC
from dataclasses import dataclass
import typing

@dataclass
class Val(ABC):
    shape: typing.Tuple[int, ...]

@dataclass
class Add(Val):
    x: Val
    y: Val

@dataclass
class Slice[T: Val = Val](Val):
    dim: int
    value: T

@dataclass
class UntaggedSlice(Val):
    dim: int
    value: Val

def do_something(val: Val) -> Val:
    if isinstance(val, Add):
        reveal_type(val) # Type of "val" is "Add"
        return val.x 
    elif isinstance(val, Slice):
        reveal_type(val) # Type of "val" is "Slice[Unknown]"
        return val.value # Type of "value" is unknown
    elif isinstance(val, Slice):
        val = typing.cast(Slice, val)
        reveal_type(val) # Type of "val" is "Slice[Val]"
        return val.value
    elif isinstance(val, UntaggedSlice):
        reveal_type(val) # Type of "val" is "UntaggedSlice"
        return val.value
    else:
        return val

Using the Pylance extension version 2025.6.106 in VSCode.

[erictraut]

Narrowing val from Val to Slice[Val] would not be sound in this case. For example, if do_something receives an object of type Slice[Add], it would be unsound for the value's type to be Slice[Val] within the block guarded by isinstance(val, Slice). Such a type would allow you to overwrite the value field with an object that is not compatible with Add.

I have considered changing the narrowing behavior of isinstance in the case where type parameters are covariant. In that circumstances, I think it would be OK to use the upper bound rather than Unknown. Likewise, it should be possible to use the lower bound (Never) in the case of contravariant type parameters. But I don't see a way around Unknown in situations where the type parameter is invariant, like in your example.

[TMVector]

Thanks for the quick reply!

Okay -- so sounds like it's due to isinstance and cast actually having different behaviour -- isinstance takes a class whereas cast takes a type, or some technical distinction like that? And when it's a type, Slice is expanded to Slice[Val] due to the TypeVar default, whereas the class doesn't have type arguments?

Regarding variance -- ah okay, I hadn't realised that the 3.12 syntax defaulted to invariant tbh, my bad. I would vote for isinstance to support the behaviour you described for covariant type parameters :)

[erictraut]

There's no relation between isinstance and cast. The two have very little in common other than both being functions.

The cast call is effectively a no-op at runtime. It simply returns the value of the second argument and ignores the first argument. It's there only for static type checkers. It tells a type checker to ignore the type it evaluated for the expression. For that reason, cast is very unsafe. I recommend against using it if at all possible. There's almost always a better solution than cast.

I hadn't realised that the 3.12 syntax defaulted to invariant

It doesn't default to invariant. It infers the variance based on the use of the type parameter within the class. I your class definition, T is used in a location that requires invariance because it's describing the type of a mutable attribute. If you're interested in the details of variance inference, you can read more about it here.

[TMVector]

Right, I guess by "behaviour" I mean in terms of how pyright interprets them, not in terms of runtime. How they change the type environment.

That's helpful on the variance piece, thanks. In my actual code I am using frozen dataclasses, so that should be fine :)

Thanks for your help!