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
_______________________________________________
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/W7Y4Z7M7QBJXKRE6IL6LEIVUSFNVFRE4/
Code of Conduct: http://python.org/psf/codeofconduct/
