Infer union from conditional definition in if statement

[JukkaL]

Maybe if a variable is initialized both in if and else blocks, the resulting type should be the union of the types of the initializers (only when using --allow-redefinitions):

if foo():
    x = 0
    # Type of x is 'int' here
else:
    x = ''  # No error here
    # Type of x is 'str' here
reveal_type(x)  # Union[int, str]

Currently the second assignment generates an error, and the type of x is int everywhere.

This is a generalization of #6232 and related to #1174 (but not a direct follow-up issue).

[bluetech]

This pattern occurs a lot in our code, specifically with None:

if condition:
    x: Optional[int] = None
else:
    x = 5

[ilevkivskyi]

@bluetech Your example already works without the explicit annotation. None is special-cased in mypy, it will infer an optional type (if None appears in the first definition).

[bluetech]

@ilevkivskyi Thanks for letting me know. I didn't realize the order matters. Looking at our code, we indeed usually put the None case in the else.

Maybe this feature can subsume this special case.

[JukkaL]

@bluetech This feature would not entirely obsolete the special case, unless we extend it to handle cases like this:

x = None
if cond():
    x = 5

It's unclear to me whether we should accept code like this:

x = 0
if cond():
    x = ''  # Should this be okay for an arbitrary rvalue type?

[dumblob]

x = 0
if cond():
    x = ''  # Should this be okay for an arbitrary rvalue type?

I think it's okay for an arbitrary rvalue if after end of the if cond(): body the first use of x will be as an lvalue (incl. for x in ..., x = , lambda: x = , lambda: for x in , etc.).

[aperiodic]

We've recently started using mypy in some of our Python projects, and we're running into this issue in places where we initialize an optional variable using this pattern:

if cond():
    x = <some_value>
else:
   x = None

The change proposed by this issue would solve it, but extending the special case to cover assigning to None in the else branch also would. Is the proposed change accepted and just waiting for someone to take on the work? If so, we would be interested in doing that. If not, would extending the special case be accepted?

[msullivan]

I would certainly accept extending the special case. I think this is actually a huge pain point.

The core suggestion in this issue is only being proposed for when --allow-redefinitions is enabled, so I'd definitely want to see at least the None case handled otherwise.

[JukkaL]

I agree with @msullivan. In my experience, code like @aperiodic'd example comes up very often, and it would be great if the None case would be supported by default, for symmetry with this case which already works:

if cond():
    x = None
else:
    x = <some_value>  # Already supported

So there are two sub-issues:

1. Support x = <value> followed by x = None with default flags (perhaps only if x is not read in between).
2. Support conditional definition with arbitrary types if using --allow-redefinition.

Case (1) seems much more important, but if also supporting (2) is not much more work, it may make sense to implement both at the same time.

[JukkaL]

Increased priority to "high" since the None case is one of the biggest type inference pain points in practice.