Optional[NamedTuple] makes mypy think a branch is unreachable

[ilinum]

In the following example, the else branch is not typechecked. As far as I've been able to narrow it down, it seems like it has to do with NamedTuple.

from typing import Optional, NamedTuple, List

NamedTup = NamedTuple('NamedTup', [('a', str)])


class Foo:
    def __init__(self) -> None:
        self.x = get_optional()
        if self.x:
            # this is typechecked
            f: str = 2  # error: Incompatible types in assignment
        else:
            # this is not typechecked
            j: str = 2  # no error
            self.mypy_does_not_typecheck_this()  # no error
            reveal_type(j)  # no error


def get_optional() -> Optional[NamedTup]:
    return None


Foo()

Here is the output from mypy and python.

$ mypy n.py
n.py:11: error: Incompatible types in assignment (expression has type "int", variable has type "str")
$ python3 n.py
Traceback (most recent call last):
  File "n.py", line 23, in <module>
    Foo()
  File "n.py", line 15, in __init__
    self.mypy_does_not_typecheck_this()  # no error
AttributeError: 'Foo' object has no attribute 'mypy_does_not_typecheck_this'

[gvanrossum]

If that's true it's disturbing. Can you boil it down to a smaller repro? (E.g. does it need to be the __init__ method in a class? Does the same thing happen in a toplevel function?)

[ilevkivskyi]

The situation boils down to this:

class N(NamedTuple):
    x: int

if N(1):
    1 + 1
else:
    1 + 'boom'  # this error is reported

x = N(1)
if x:
    1 + 1
else:
    1 + 'boom'  # but this is not

y: N
if y:
    1 + 1
else:
    1 + 'boom'  # nor this

[ilinum]

@ilevkivskyi thanks for narrowing it down!

[gvanrossum]

So it boils down to "a variable of type (some named tuple) is always considered false" ?

[ilevkivskyi]

On a second thought, it seems to me this is not a bug either. Tuples indeed cannot be false (only an empty tuple, but mypy treats it correctly). Also the initial example is treated correctly with --strict-optional. Please close this issue if you agree.

[JukkaL]

A non-empty tuple could be false if a subclass overrides __bool__. Not sure if that's something we should be prepared for. We already sometimes assume that certain subclasses that might plausibly exist don't actually exist.

[ilevkivskyi]

A non-empty tuple could be false if a subclass overrides __bool__.

Yes, this is why I left one of the two issues open. But TBH I think such situations are very rare.

[JukkaL]

I encountered this today. This also happens with regular tuples (when not using strict optional):

from typing import Tuple

def f(x: Tuple[int, int]) -> None:
    if x:
        print(1)
    else:
        1 + ''  # No error

f(None)

The above behavior is clearly a bug. Let's make this issue only about the non-strict-optional case, as discussing the strict optional behavior only confuses things.

[JukkaL]

I have a possible fix that I need to validate still.