On Thu, Jan 13, 2022 at 04:23:09AM -0000, Dennis Sweeney wrote:
Like others expressed, I don't like the idea of the typing and non-typing parts of Python separating.
Its a good thing that this PEP doesn't separate the typing and non-typing world. The arrow syntax will be a plain old Python expression that is usable anywhere, not just in annotations. It will only be *useful* in code that makes use of generic types, whether that is for annotations or runtime introspection, or exploration in the REPL, but that's okay. `is` is a built-in operator despite have exceedingly limited use-cases and sometimes being an attractive nuisance.
Has anyone considered adding a new special method like `__arrow__` or something,
In the absense of any useful functionality for this arrow syntax, I think that is a clear case of YAGNI. As it turns out, I do have a use-case for an arrow operator, but it wouldn't use a dunder either. And since my use-case doesn't have a PEP written, it would be unfair of me to derail the conversation with a half-baked proposal that is nowhere near ready to be a PEP. But if it gets rejected, all bets are off :-) If you do have some non-trivial uses for the arrow operator, it would be good to hear what they are.
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].
That wouldn't work. The PEP explains that they don't want people to be able to write: int -> bool without the parentheses. I agree with them. I think it is important that the syntax be visually similar to an anonymous function signature with the parameter names scrubbed out: def func(a:int) -> str https://www.python.org/dev/peps/pep-0677/#parenthesis-free-syntax Analogy: we require generator comprehensions to be surrounded by parentheses: it = (expr for i in sequence) In the desired syntax: (int) -> bool that is not a tuple. Its a parenthesised comma-separated expression. The same objection applies to using the `>>` operator. There is no way to force `(int) >> str` or prevent `int >> str`.
I would find that sort of semantics more agreeable since Python already has operators that dispatch to dunder methods,
And Python already has operators which don't: - `or` and `and` - `is` and `is not` - name binding (assignment) `=` - walrus assignment operator `:=` - ternary `if else` operator. So there is plenty of precedent for dunder-less operators. -- Steve