I think this is reasonable, even outside annotations. Someone should start a discussion on python-dev and draft a PEP.

—Guido

On Mon, Jan 25, 2021 at 02:50 Matthew Rahtz via Typing-sig < typing-sig@python.org> wrote:

+1 for this being a potentially useful future. We've run into this when trying to write type stubs for certain TensorFlow operations in https://github.com/deepmind/tensor_annotations - as a concrete example:

# reduce_sum has a signature (input_tensor, axis=..., keepdims=...,
name=...)
# But when keepdims=True, because the result is always the same rank
# as `input_tensor`, we don't care about the `axis` argument:

@overload
def reduce_sum(input_tensor: Tensor2[A1, A2],
               axis=...,
               keepdims: Literal[True],
               name=...) -> Tensor2[A1, A2]: ...

@overload
def reduce_sum(input_tensor: Tensor3[A1, A2, A3],
               axis=...,
               keepdims: Literal[True],
               name=...) -> Tensor3[A1, A2, A3]: ...

On Sat, 23 Jan 2021 at 14:15, Sebastian Rittau srittau@rittau.biz wrote:

...

When working with overloads, it would often make sense if an argument without default could follow an argument with defaults. Take this simplified example:

@overload def foo(arg1: str = ..., arg2: Literal[True]) -> str: ... @overload def foo(arg1: str = ..., arg2: Literal[False] = ...) -> bytes: ...

This is invalid syntax. Currently, the workaround is fairly cumbersome, redundant, and hard to read (especially in non-toy examples):

@overload def foo(arg1: str, arg2: Literal[True]) -> str: ... @overload def foo(arg1: str = ..., *, arg2: Literal[True]) -> str: ... @overload def foo(arg1: str = ..., arg2: Literal[False] = ...) -> bytes: ...

Would it make sense to relax Python's syntax to allow this case? And what would that mean for non-overloaded functions using this syntax?

• Sebastian

---

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: mrahtz@google.com

---

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: guido@python.org

Am 25.01.21 um 17:48 schrieb Eric Traut:

I'd strongly advise against this.

It would seem to lead to ambiguities when matching arguments with parameters. For example:

@overload
def foo(arg1: bool=..., arg2: Literal[True]) -> str: ...

foo(True) # Does this match the overload?

Would the rule be "if there's any possible way to construe an argument list as matching an overload, it should be matched"?

This would follow normal Python rules. In the example above, it doesn't match as calling this would be a runtime error:

```python def foo(arg1: bool=..., arg2: Literal[True]) -> str: ... foo(True) ```

The code for matching arguments with parameters is already extremely complicated in a type checker because it needs to deal with *args parameters, **kwargs parameters, position-only separators, keyword-only separators, unpack operators on args, TypeVar assignments, ParamSpec parameter assignments (P.args, P.kwargs), and *args with variadic type variables. More complexity in this code is not needed!

This seems to be a trade-off between type checker complexity and user code/stubs complexity. I am obviously biased here, but simpler user code and stubs seems more desirable to me than simpler type checkers as it scales far worse.

- Sebastian

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).