`TypeGuard` should change the type to an intersection like it does with `isinstance`

[KotlinIsland]

from typing import TypeGuard

class A:
    def foo(self): ...
class B:
    def bar(self): ...

def guard(it: object) -> TypeGuard[A]: ...

b = B()
if guard(b):
    b.foo()
    b.bar() # error: "A" has no attribute "bar"

if isinstance(b, A):
    b.foo()
    b.bar() # no error

When a conditional statement includes a call to a user-defined type guard function, and that function returns true, the expression passed as the first positional argument to the type guard function should be assumed by a static type checker to take on the type specified in the TypeGuard return type

@erictraut The pep for TypeGuard doesn't mention this scenario and pyright behaves the same as mypy.

Currently within the isinstance block, mypy will narrow the type to an intersection of both types <subclass of "B" and "A"> but within the TypeGuard block, mypy will instead change the type entirely to the guarded type.

Original description

Originally this issue was about the more specific scenario of a derived type being widened to the guarded type.

class A:
    ...
class B(A):
    def foo(self): ...

def foo(it: object) -> TypeGuard[A]: ...

b = B()
if foo(b):
    b.foo() # error: "A" has no attribute "foo"

When a conditional statement includes a call to a user-defined type guard function, and that function returns true, the expression passed as the first positional argument to the type guard function should be assumed by a static type checker to take on the type specified in the TypeGuard return type

@erictraut The pep for TypeGuard doesn't mention this scenario and pyright behaves the same as mypy.

In TypeScript the type guard will narrow the type to an intersection of the both types, but Python doesn't have Intersections (yet)

I think the pep should be updated such that if the type guarded type is a super type of the input then it shouldn't be 'narrowed' (actually it's widened) it should be left alone.

Workaround

Currently this only works in pyright.

from typing import TypeGuard, TypeVar

class A:
    ...
class B(A):
    def foo(self): ...

T_foo = TypeVar("T_foo", bound=A)

def foo(it: T_foo | object) -> TypeGuard[T_foo]: ...

b = B()
if foo(b):
    b.foo() # works!

[erictraut]

The PEP does mention this, and it's intended behavior. Search for "Enforcing Strict Narrowing".

[KotlinIsland]

Isn't that more about the relationship between the type annotation of the input type and the type annotation of the guard?

This is more about the relationship between the static type of the value and the type annotation of the guard.

[KotlinIsland]

On that unrelated note, why did you make it bivariant anyway? Nothing else that I know of in Python is bivariant? seems more like a typescript kind of thing.

[erictraut]

I don't think that restriction can be enforced in general. TypeGuard isn't typically used in cases where there's a simple subtype relationship. You can use isinstance if that's what you're interested in. User-defined type guards are used for more complex situations where the subtype relationship is often not well defined by the type system. So no, I don't agree with that proposed change to the PEP.

[KotlinIsland]

Would you think it's a good idea to amend the pep if intersections are added?

[erictraut]

No, probably not.

I'm also skeptical that intersection types will ever make it into Python because its type system is a combination of nominal and structural types. Intersections really make sense only for structural types.

[KotlinIsland]

I think intersections and useful for nominal types, Scala has recently implemented them, Java supports them to some extent and Kotlin is thinking about supporting them(Kotlin actually fully supports them internally, they are just non-denotable).
https://docs.scala-lang.org/scala3/reference/new-types/intersection-types.html
https://youtrack.jetbrains.com/issue/KT-13108

[KotlinIsland]

Hey, I thought of a workaround

from typing import Coroutine, TypeVar
from typing_extensions import TypeGuard


class MyBasedCoroutine(Coroutine[None, None, None]):
    def my_method(self):
        ...

T = TypeVar("T", bound=Coroutine[None, None, None])

def iscoroutine(val: T | object) -> TypeGuard[T]:
    ...


c: MyBasedCoroutine = ...

if iscoroutine(c):
    c.my_method()  # Based!

What do you think?

[erictraut]

That's clever! If you want this to work with arbitrary coroutines, I recommend setting the bound to Coroutine[Any, Any, Any]. Other than that, it looks good to me.

[KotlinIsland]

I feel like that should be the default behavior of TypeGuard though, I feel like I now have to add this extra boilerplate to every TypeGuard I write.

[KotlinIsland]

Here's an example that clearly shows this disparity of builtin type guards and user type guards:

from typing import TypeGuard

def guard(it: object) -> TypeGuard[int]: ...

class A:
    def foo(self):
        ...

a = A()

if isinstance(a, int):
    a.foo()
   reveal_type(a)  # note: Revealed type is "__main__.<subclass of "A" and "int">"

if guard(a):
    a.foo()  # error: "int" has no attribute "foo"
   reveal_type(a)  # note: Revealed type is "builtins.int"

[JelleZijlstra]

mypy is implementing TypeGuard as specified here and changes to TypeGuard should be discussed on the typing tracker.