The problem could also be solved by putting a sentinel in the default value. For example, where FAKE_DEFAULT_VALUE is something to be bikeshedded:
```
@overload
def foo(arg1: str = ..., arg2: Literal[True] = FAKE_DEFAULT_VALUE) -> str: ...
@overload
def foo(arg1: str = ..., arg2: Literal[False] = ...) -> bytes: ...
```

The semantics would be something like: type checkers never match overloads to calls which look like they would result in an argument being assigned FAKE_DEFAULT_VALUE.

On Mon, 25 Jan 2021 at 13:47, Guido van Rossum <guido@python.org> wrote:
On Mon, Jan 25, 2021 at 11:15 AM Eric Traut <eric@traut.com> wrote:
Thanks for the clarification. If argument/parameter matching follows normal Python rules, then my concern is lessened.

Do you happen to know where in the Python parser and/or runtime this limitation is enforced today? In pyright, the check for parameters without defaults after parameters with defaults is done in the parser. This check would need to be moved out of the parser to a later stage because it would need to be conditionalized based on the presence of the @overload decorator. That's doable, but I'm wondering if that same work will need to be done in all type checkers and the Python parser and runtime as well.

You're right, this is generally done in the parser. IMO the proposal could only succeed if it made the point that *generally* we should allow this in function definitions. Reasonable and unsurprising semantics are available, the question is how often is this needed? I think I have come across this need occasionally, but I can't quantify it. I think only changing this for `@overload` is not going to fly (since it really does require changes to the parser).

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Typing-sig mailing list -- typing-sig@python.org
To unsubscribe send an email to typing-sig-leave@python.org
https://mail.python.org/mailman3/lists/typing-sig.python.org/
Member address: hauntsaninja@gmail.com