On Fri, Jan 14, 2022 at 2:12 AM Steven Troxler <steven.troxler@gmail.com> wrote:
Using an operator is an interesting idea, and we should probably call it out as an alternative in the PEP. It's not a substitute for the current PEP from the standpoint of typing-sig for a few reasons:
(A) We care that the syntax be forward-compatible with supporting named arguments, as outlined in the "Extended Syntax" section of Rejected Alternatives and I don't think an operator-based syntax would extend to that.
(B) We like supporting `(**P) -> bool` and `(int, **P) -> bool` for PEP 612 ParamSpec and Concatenate; this makes it much easier to write types for decorators, which are a common use case. It would be tricky to do this using an arrow operator.
Ah, good point(s), so it wouldn't really work unless there could be some dict/tuple hybrid and that would be a much bigger change.
(C) I'd hesitate to add a dunder method on the tuple type, for reasons already mentioned here as well as the fact that it would force us to write unary callables - which are the most common kind - as `(int,) >> bool`
This one's easily solved with a reflected dunder though - "(x,y,z) + q" can be handled by q.__radd__ without any help from the tuple. But yeah, it'd only work for tuples, so that's the end of that theory. Oh well. ChrisA