+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