On Fri, Jan 14, 2022 at 2:12 AM Steven Troxler <[email protected]> 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 _______________________________________________ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/IWX6HY34E7ZKVPIOZG6YKI7MKO7LRUSS/ Code of Conduct: http://python.org/psf/codeofconduct/
