Type-narrowing does not apply across 2 branches having the same condition within the same block

[syastrov]

• Are you reporting a bug, or opening a feature request? Feature request

• Please insert below the code you are checking with mypy,

  
  from typing import Optional

def my_func() -> bool: return True

created: bool = my_func() a: Optional[int] = None if created: a = 1 z = a + 1 # This is OK

if created: x = a + 1 # Unsupported operand types for + ("None" and "int")

* What is the actual behavior/output?

$ mypy a.py a.py:13: error: Unsupported operand types for + ("None" and "int") a.py:13: note: Left operand is of type "Optional[int]" Found 1 error in 1 file (checked 1 source file)

* What is the behavior/output you expect?

No errors. Mypy should be able to narrow the type of `a` to just `int` in the second `if` block, because it narrowed it to that type already the first `if` block and they have the exact same condition.

You can argue that it's easy to workaround it be merging the `if` blocks, but in real-life code, there could easily be intervening code that is not trivial to move around.

* What are the versions of mypy and Python you are using?
mypy 0.750+dev.5b73e2a5e62d3da723ac517fabacaa2a0c8cdf3c
Python 3.7.4

* What are the mypy flags you are using? (For example --strict-optional)
--strict-optional

[msullivan]

This would be handy in a few situations, but also require a major extension of our narrowing mechanisms for a use case that I don't think is that common.

My inclination is to say we aren't going to do this, though I'm curious what @JukkaL and @ilevkivskyi think about whether its worth leaving open as a feature request.

[ilevkivskyi]

I think it is fine to keep this as a low-priority feature request.

In general I think there is a cluster-issue formed (I think I mentioned this before elsewhere) around cleaning-up the binder, partial types, inferring unions from if-else, moving towards SSA in --allow-redefinition, and generally maybe making binder and related machinery more abstract-interpreter-like. For this I would like to have some pool of potential use-cases we might want to support.