First of all, thank you for authoring a really well-written PEP. tl;dr: I find it very troubling that we are going on a path where need to increase the language complexity (syntax) only in the cause 'easier' typing. So I am opposed to this change.
Most of the native typing use cases until now (PEP 585 / PEP 604) was using the existing syntax, with slight adjustments on runtime. And personally, I really liked them (being able to write `list[int | str]` is nice), but not as much as I like the simplicity of the language. I think the new syntax proposal for only a typing use case is really destructive when we already have a very formal way of creating callable types. I personally don't think it is verbose (as claimed by the PEP), since the only thing that we have an extra is the `Callable` name. Aside from these concerns, a few comments on the actual proposal: - The syntax itself would probably confuse people, considering in other languages (like javascript) the arrow functions are a thing that loosely translates to our lambdas. People might try to write code like `(x, y) -> x + y`, with the expectation that it would work (since it is a valid syntax now), but it would immediately throw an error (if x/y is not defined) and create confusion. - Callables that return callables look very awkward with a double arrow. `) -> (int, str) -> R:` (compared to `) -> Callable[[int, str], R]:`. This was one of the examples that really made me look twice to understand. - `async` keyword used to be coupled with `def`/`for`/`with`, but without any of these, it doesn't feel good to have it as some sort of prefix to these expressions. I think it would be nice if the PEP can address how much of the code out there uses `Callable[..., Awaitable[...]]` syntax, since from what I understand by the current proposal `async (int, str) -> bool` is the same with `(int, str) -> Awaitable[bool]`, which is, in theory, a new syntax that we might be adding for a very restricted use case. - The parameter part (`(x, y) -> `) seem to be even diverging from an actual expression (by allowing standalone [double-]starred operations, and disallowing `(int, ...) ->`), which I think would complicate the actual parsing process (even though we have an advanced parser in CPython, that does not mean community maintained projects such as jedi, parso, black will have one). - Out of 4 concerns that are listed on the PEP about the current callable syntax; only 1 is about the actual runtime behaviour, which even if I did not agree initially, we have other solutions. Like an open issue on the tracker about making `callable()` generic https://bugs.python.org/issue42102. - The other 3 is pretty much the same, claiming the syntax is dense. Which I partly agree on. We probably could find other solutions (using tuples to represent the parameter group, etc.), but I do not see those points as very big deals (at least not as big as adding a very complicated piece of new syntax). I would assume some of these were previously discussed during the typing-sig/python-dev threads, but as someone who recently learned about this proposal, I feel like this is really overworked for a problem that is (subjectively, again) small. _______________________________________________ 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/FI4AFU3I25PECARIH2EVKAD5C5RJRE2N/ Code of Conduct: http://python.org/psf/codeofconduct/
