Handling de-facto positional-only arguments with overloads

[Michael0x2a]

In my PR for updating the mypy docs, @gvanrossum pointed out that one of my examples didn't typecheck -- the simplified repro was this:

class A: pass
class B: pass

@overload
def foo(a: int) -> A: pass
@overload
def foo(a: int, b: int) -> B: pass
def foo(*args: int) -> Union[A, B]:
    raise NotImplementedError()

After debugging, I realized that the checks are actually technically correct: the overloads suggest that running foo(a=1, b=2) is type-safe; that call will crash at runtime.

This feels a bit annoying though, so I'm thinking it'd be nice if we could relax these checks -- basically, allow the existence of "de-facto positional-only arguments".

I'm thinking one way we can do this is to:

1. Relax the overload definition checks so they ignore the argument names
2. Perform an extra check every time we call an overload: if the overload has an implementation, we check and see names match and report a (custom) error if they don't.

So under this proposal, foo would continue to type-check, but we'd report an error if somebody tried doing foo(a=1, a=2).

The main disadvantage is that this would cause feature disparity with overloads in stubs since stubs don't allow you to include an implementation. We could either live with this or maybe allow users to add an implementations with empty bodies in stubs if we really want to maintain parity.

Thoughts? (I wanted to file an issue to get consensus/see if anybody is able to come up with a better solution before I start implementation.)

[JelleZijlstra]

In stubs, you can just use the __a syntax to indicate that the arguments are positional-only, right?

Perhaps that's also what we should have users do in implementation files.

[Michael0x2a]

Huh, I didn't know that was even a thing.

It looks like the __a syntax actually already works in regular .py files, so I guess problem solved?

I guess the only downside is that it leaves the signatures looking sort of ugly when you have a lot of those parameters -- maybe I just need to find a different example for the docs altogether...

I'll close this in a little bit if nobody else chimes in.

[ilevkivskyi]

I think there is still an action item here. Using __name is quite non-obvious, so I would propose to detect the situation where the error is because of missing **kwargs in the overload implementation and add a note that proposes to either:

• Use positional only __name if this is the intention
• Add **kwargs to the implementation otherwise

[nyanpasu64]

Related failure case: Overloads have meaningful parameter names, but implementation uses arg1 and arg2=None.

@overload
def add_row(right: Type[Right]) -> Any:
    ...

@overload
def add_row(left: Type[Left], right: Type[Right]) -> Any:
    ...

@overload
def add_row(label: str, right: Type[Right]) -> Any:
    ...

def add_row(arg1: Any, arg2: Any = None) -> Any:
    impl

[hauntsaninja]

mypy is behaving as expected, and with Python 3.7 dead it is much easier to mark positional-only args