Doesn't correctly match overloads when calling method using conditional arguments

[FFY00]

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

Bug report

• Please insert below the code you are checking with mypy,
  or a mock-up repro if the source is private. We would appreciate
  if you try to simplify your case to a minimal repro.

from typing import List, Optional


def example(data: Optional[List[int]] = None, size: int = 0) -> None:
    buffer = bytearray(data if data else size)
    print(buffer)


example(size=3)
example(data=[1, 2, 3])

• What is the actual behavior/output?

error: No overload variant of "bytearray" matches argument type "object"
note: Possible overload variants:
note:     def __init__(self, ints: Iterable[int]) -> bytearray
note:     def __init__(self, length: int) -> bytearray
note:     <2 more non-matching overloads not shown>

I am forced to replace it with

if data:
    buffer = bytearray(data)
else:
    buffer = bytearray(size)

• What is the behavior/output you expect?

I would expect mypy to pass, as I believe the arguments passed to the bytearray constructor match the overloads.

• What are the versions of mypy and Python you are using?
  Do you see the same issue after installing mypy from Git master?

mypy 0.782
master is the same

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

mypy --strict

[hauntsaninja]

I'm kind of surprised I can't seem to find other issues along these lines. mypy's joining int and List[int] here to be object, when you'd want it to be Union[int, List[int]] (which you can cast to, and things will work).

Note https://github.com/python/mypy/wiki/Type-Checker seems to claim

[doing so] will make type checking much slower (or even non-terminating), and will force mypy to emit long and incomprehensible error messages

but that's not a statement I immediately see the truth of.

It's also possible that there's some ad hoc workaround involving type context.

[gvanrossum]

This definitely used to be a common feature request, but the core mypy team has always held that in many cases this would not be helpful. That's what that wiki page is trying to say. It's true that that is an intuition without data. But it's not cheap to test the alternative hypothesis, alas.

We could ask @JukkaL if he has a specific argument, or if there is literature about this topic; and if he would object to a per-module (?) flag to change this.

[JukkaL]

This is essentially the same as #5392. The main problem is that changing type inference would result a lot of work for existing users. Having a flag to switch between behaviors is a possibility and would allow existing users to continue using the old semantics.

[erictraut]

This bug appears to have been fixed at some point. I can no longer repro it with the latest version of mypy.

[hauntsaninja]

I think underlying bug is still there and this was fixed by a change in typeshed types, but I'll take it