Infer type from "assert isinstance()" even if types aren't overlapping

[JukkaL]

I think that we should infer x to be str in this example (this is based on a user issue):

def f(x: int):
    assert isinstance(x, str)
    x + ''  # should be fine
    x + 2  # should be an error

Here the rationale is that if the isinstance checks passes, x will be a string, not an integer.

Currently this doesn't work since mypy considers int and str to be non-overlapping. This is perhaps okay for if isinstance() (though perhaps only if variable has a type variable type with values such as AnyStr), but for assert isinstance() it doesn't make sense.

[refi64]

I would argue that this should be an error; if a function expects its int argument to be a string, then there's probably a bug in either the type declarations or the function itself.

[JukkaL]

Yeah, the simple example I gave doesn't make sense. Here is another example:

class Thingye: ...
class SomeMixin(...): ...
class ThingyeWithSome(Thingye, SomeMixin): ...

def f(t: Thingye) -> None:
    ...
    if isinstance(t, SomeMixin):
        # do some SomeMixin specific stuff
        ...

[rwbarton]

You might want to do some Thingye stuff in that if branch too though. A case for intersection types? Related to #1539 too.

[rwbarton]

@JukkaL, according to my experiments, in the case above, mypy currently does not check the body of the if branch at all. (Even reveal_type is silently ignored.) Is that intentional?

[JukkaL]

Yes, that is used for type checking functions that use AnyStr, etc. We type check those functions multiple times, and often we ignore some parts of the function on some passes, as otherwise we would get false positives.

However, if there are no type variables with values in the current scope, it's not the right thing to do.

[rwbarton]

Ah, I see. I wonder if type checking the branch with the string having an intersection type would work, but I bet there would be some cases where type inference wouldn't do the right thing...

[ilevkivskyi]

This is essentially a duplicate of #3603 that has some ideas how to fix this.