> Has anyone considered adding a new special method like `__arrow__` or > something, that would be user-definable, but also defined for tuples and > types as returning a Callable? For example `int -> str` could mean > Callable[[int], str], and (int, str) -> bool could mean Callable[[int, str], > bool]. I would find that sort of semantics more agreeable since Python > already has operators that dispatch to dunder methods, and anyone who knows > how that bit of Python works would automatically mostly know how the new > operator works.
I would personally argue that this would make the situation worse, considering the complexity would be increased with no possible use case on the route beside type annotations. On Thu, Jan 13, 2022 at 7:30 AM Dennis Sweeney <sweeney.dennis...@gmail.com> wrote: > > Like others expressed, I don't like the idea of the typing and non-typing > parts of Python separating. > > Has anyone considered adding a new special method like `__arrow__` or > something, that would be user-definable, but also defined for tuples and > types as returning a Callable? For example `int -> str` could mean > Callable[[int], str], and (int, str) -> bool could mean Callable[[int, str], > bool]. I would find that sort of semantics more agreeable since Python > already has operators that dispatch to dunder methods, and anyone who knows > how that bit of Python works would automatically mostly know how the new > operator works. > > If I understand right, this is a sort of combination of two things for which > there is more precedent: first, adding a new operator based on the needs of a > subset of users (the @ operator and __matmul__), and second, adding new > operators to existing objects for the sake of typing (like the list[int] > syntax in which type.__getitem__ was implemented to dispatch to > the_type.__class_getitem__). > > If people don't want to add a new operator and dunder, I assume using the > right shift operator like `(int, bool) >> str` would be too cheesy? > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/GTYLK4QA6DHQDZH7NLYLELYCFUKOTNDT/ > Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GDLOI64UZRCSG7GGSNM67MSKFWQ4LI5B/ Code of Conduct: http://python.org/psf/codeofconduct/
