+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:

```python
# 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