Skip to content

isinstance(instance, SubClass) loses generic type instead of narrowing #817

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
marcin-serwin opened this issue Jul 9, 2020 · 7 comments
Closed
Labels
addressed in next version Issue is fixed and will appear in next published version enhancement request New feature or request

Comments

@marcin-serwin
Copy link

Describe the bug
When performing an isinstance check on object with generic type, the type information of variable type is lost.

To Reproduce
Standard pyright configuration with strict mode enabled.

# pyright: strict
from typing import Generic, TypeVar

T = TypeVar("T")


class A(Generic[T]):
    pass


class B(A[T]):
    pass


def f(a: A[T]) -> B[T]:
    assert isinstance(a, B)
    return a

Expected behavior
No errors. After assert type of a is B[T].

Actual behavior
17:12 - error: Return type, "B[Unknown]", is partially unknown
After assert type of a is B[Unknown]

@erictraut
Copy link
Collaborator

This is the correct behavior. The assert statement validates that a is of type B, but there is not type argument specified. PEP 484 indicates that when type arguments to a generic class are omitted, the type checker should assume Any. Pyright uses a special form of Any that it calls Unknown so it can track cases where types are omitted. Since you have indicated strict typing mode, Pyright is reporting that you have a partially-unknown type.

If you change your code as follows, it should work as you expect:

    assert isinstance(a, B[T])

@erictraut erictraut added the as designed Not a bug, working as intended label Jul 9, 2020
@marcin-serwin
Copy link
Author

marcin-serwin commented Jul 10, 2020

If we change the last lines to:

def f(a: A[T]) -> B[T]:
    assert isinstance(a, B[T])
    return a

f(B())

the code will produce TypeError at runtime:

TypeError: Subscripted generics cannot be used with class and instance checks

As per documentation this construction is not valid Python code since isinstance should not be used with types.

@marcin-serwin
Copy link
Author

Also, if this helps, I think this is the analogous bug in MyPy: python/mypy#949

@erictraut
Copy link
Collaborator

Yes, you are correct. My proposed workaround unfortunately won't work.

It might seem straightforward to simply assume that isinstance(a, B) implies that a is narrowed to type B[T], but this is an unsafe assumption. Consider the following class hierarchy:

class A(Generic[T]):
    pass


class B(A[str], Generic[T]):
    pass

Let's assume in this case that a value of type A[str] is passed to f. There's no way for the type checker to determine that it's of type B[str] after the assert statement. The only safe assumption at this point is that it's type B[Unknown]. That is consistent with mypy's behavior (although mypy doesn't have the notion of "unknown" or a strict mode, so it uses B[Any] in this case).

Here are some additional workarounds (none of which are very elegant):

  1. Use a cast operator:
def f(a: A[T]) -> B[T]:
    assert isinstance(a, B)
    b = cast(B[T], a)
    return b
  1. Suppress the warning using a # type: ignore comment.
def f(a: A[T]) -> B[T]:
    assert isinstance(a, B)
    return a  # type: ignore
  1. Disable the reportUnknownVariableType diagnostic rule for this file.
# pyright: strict, reportUnkownVariableType=false

@marcin-serwin
Copy link
Author

Thanks for the clarification. On a related note I think it would be nice if pyright warned about the usage of isinstance(a, B[T]) and such as erroneous code.

@erictraut
Copy link
Collaborator

That's a good suggestion.

@erictraut erictraut added enhancement request New feature or request addressed in next version Issue is fixed and will appear in next published version and removed as designed Not a bug, working as intended labels Jul 10, 2020
@erictraut
Copy link
Collaborator

Your suggestion is now implemented in Pyright 1.1.52, which I just published. It will be included in the next published version of Pylance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addressed in next version Issue is fixed and will appear in next published version enhancement request New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants