issubclass vs. is for narrowing types

[stephenfin]

The below is a much reduced form of an existing conversion function I'm adding typing to. Its job is to convert a provided "raw" value (received from an API, fwiw) to an expected type if possible else provide a dummy value of the expected type if it can't do the conversion.

from typing import Any, TypeVar

_T = TypeVar('_T', str, int, list[Any], covariant=False)


def convert_value(value: Any, data_type: type[_T]) -> _T:
    if data_type is list:
        if isinstance(value, (list, set, tuple)):
            return data_type(value)
        else:
            return [value]
    elif data_type is int:
        if value.isdecimal():
            return data_type(value)
        return data_type()
    else:  # data_type is str
        return data_type(value)

A sample user of which might look like:

>>> convert_value('abc', list)
['abc']
>>> convert_value('123', str)
123
>>> convert_value('abc', str)
0

This doesn't behave as I expect and yields the following error:

❯ mypy --strict convert.py
convert.py:9: error: No overload variant of "int" matches argument type "list[Any] | set[Any] | tuple[Any, ...]"  [call-overload]
convert.py:9: note: Possible overload variants:
convert.py:9: note:     def int(str | Buffer | SupportsInt | SupportsIndex | SupportsTrunc = ..., /) -> int
convert.py:9: note:     def int(str | bytes | bytearray, /, base: SupportsIndex) -> int
convert.py:11: error: Incompatible return value type (got "list[Any]", expected "str")  [return-value]
convert.py:11: error: Incompatible return value type (got "list[Any]", expected "int")  [return-value]
❯ mypy --version
mypy 1.11.2 (compiled: no)

If I replace the data_type is x invocations with issubclass(data_type, x), things work as expected. However, I would have assumed the identity check would be sufficient given we're comparing explicit, invariant types. Could someone explain what I'm missing?

[Daverball]

data_type could always be a subclass of list or int as well, using a constrained type var does not prevent that. Variance doesn't really have any meaning in generic functions, it just has to find a T that produces a signature that could accept your input type. So if you substitute int any subclass of int can be passed into the function, just like if you had annotated the function with int.

So is is not sufficient for narrowing classes that haven't been decorated with @final to prevent subclasses. Type checkers could narrow to int & ~Exactly[int] in the negative case but in practice that's not really useful, unless you're working with ADTs where you have a finite statically known number of subclasses, so they usually make it a no-op.

That being said, the the fact that mypy makes it a no-op both in the positive and negative case can be a little frustrating, since the positive case could be narrowed safely, but at the same time it's probably a good idea to discourage the use of type identity for type narrowing, since it's not reliable.

[stephenfin]

Okay, I had suspected the answer likely involved the possibility of subclasses of those primitives, but I hadn't realised invariance wasn't a possibility here. I agree that mypy making it a no-op is frustrating and it would be a nice little UX boost if mypy was able to highlight what it was doing. I suspect this is very much a corner case though. Thanks for your time/help!

[JelleZijlstra]

Variance isn't even really the issue here, the problem is that even if you use constrained TypeVars (like your _T), instances of subclasses are still assignable to the TypeVar. When the type checker sees a call to convert_value(), it must solve _T to exactly str, int, or list[Any], which then turns the signature into essentially def convert_type(value: Any, data_type: type[str]). But a subclass of str is still assignable to type[str].