Multiple Inheritance Makes Mypy think an if branch is unreachable.

[ilinum]

In the following example, the branch of an if-statement is not being typechecked.

class Parent1: pass

class Parent2: pass

class Child(Parent1, Parent2): pass

def goo(p: Parent1) -> None:
    if isinstance(p, Parent2):
        # this branch is not typechecked
        1 + 'boom'  # no error from mypy here.


goo(Child())

Here is the output from mypy and python.

$ mypy i.py 
$ python3 i.py 
Traceback (most recent call last):
  File "i.py", line 13, in <module>
    goo(Child())
  File "i.py", line 10, in goo
    1 + 'boom'  # no error from mypy but there's an error at runtime
TypeError: unsupported operand type(s) for +: 'int' and 'str'

[gvanrossum]

These bugs are pretty good finds! How'd you find them?

[ilinum]

I am working on a patch for --html-report to mark unreachable code as Any (currently, it marks the code as typed).

So I just compared the output of new --html-report and the old one.

[JukkaL]

This has come up before as well. Intersection types would perhaps be the cleanest way to support it, but just faking it by internally generating dummy multiply inheriting classes would perhaps work. So in the original example the type of p after isinstance would be a newly created empty class that looks like Child (it needs to be generated since generally something like Child can't be assumed to be visible to mypy at any given scope).

[ilevkivskyi]

I would vote for implementing this using an internal intersection type. It looks like Intersection appeared here and there several times, so that we might want to make it available in PEP 484 in the future.

[JukkaL]

I'm still not excited about general intersection types, though I'm not quite sure if that is what you proposed. I expect that implementing them would require a large amount of work and would complicate future work on mypy features, whereas the hack I proposed would be a local change. It's hard to justify adding heavy machinery for this issue, which a relatively rare edge case.

Here's how we could implement semi-general intersection types without full-on general intersection types (similar to current UnionType). This would be a generalized version of my proposed hack -- we'd try to represent the intersection using only the types we already have at our disposal.

We'd implement something like make_fake_intersection(t1, t2) that generates a dummy TypeInfo that basically is a subclass of t1 and t2 if both are Instance types. We can also support some other cases (these are just a few examples, and I'm not sure if all of these are worth it):

• For protocols, the intersection would again be a new TypeInfo.
• Intersection of a callable and Instance could be a TypeInfo with __call__.
• Intersection of any type t with Any would perhaps be Union[t, Any] -- though that sounds a little unexpected.
• An intersection of two callables could perhaps be Overloaded.
• What about the intersection involving a union? Maybe Intersection[Union[t, s], u] == Union[Intersection[t, u], Intersection[s, u]].

In some cases we can't represent the intersection using the current type system features. An example would be the intersection of Type[X] and Tuple[int, str]. In cases like this we could generate an error and the user would have to use a cast or # type: ignore, or they can refactor their code. I expect that these cases would be very rare, though.

The generated TypeInfos would be named descriptively, such as <subclass of X and Y>. We'd perhaps need to add the generated TypeInfo to a symbol table as well.

This sounds a little ad hoc, but on reflection it doesn't sound terrible to me and it's actually somewhat principled. If we assume that intersections are only rarely needed (for the sake of the argument, let's say once every 50 kLOC on average), then supporting the most common 95% of intersection types would be good enough to require programmer intervention only very rarely (once every 1 MLOC based on previous assumptions). This would be a trivial fraction of all the other work needed to annotate such as large codebase, and any improvements to intersection types would have minimal practical significance for most users.

Anyway, I'm not yet convinced that generalized (fake or not) intersection types are among the most important potential features in the near future.

[ilevkivskyi]

Here's how we could implement semi-general intersection types without full-on general intersection types

I am happy with this. I don't want to implement a fully functional intersection as well.

What about the intersection involving a union?

Yes, we can do some basic "set algebra"

In some cases we can't represent the intersection using the current type system features. An example would be the intersection of Type[X] and Tuple[int, str]. In cases like this we could generate an error and the user would have to use a cast or # type: ignore, or they can refactor their code. I expect that these cases would be very rare, though.

Maybe we can generate UninhabitedType in such cases?

We'd perhaps need to add the generated TypeInfo to a symbol table as well.

Yes, we will need to check that serialization/deserialization works properly (I remember having some problems when I tried "fake" TypeInfos for protocol joins).

[ddfisher]

Maybe we can generate UninhabitedType in such cases?

This will make mypy think the branch is unreachable.

[ilevkivskyi]

This will make mypy think the branch is unreachable.

So that we are back at the original problem, but in the much narrower situation of really weird combinations like Type[X] and Tuple[int, str]. Anyway, this is just a possible option, I am also fine with emitting an error like Jukka proposed.

[JukkaL]

Another thing that is unclear is how to make subtyping, joins, meets and other type operations would work with fake TypeInfos. Any class that inherits from X and Y should be a subtype of Intersection[X, Y]. Looks like we may need to do some special casing for fake typeinfos after all. However, if intersection types would only be inferred internally for isinstance tests, we could probably get away with not having subtyping and such do the right thing.