Hello typing-sig,
We've drafted a PEP to support callable syntax [1]. It is still in progress but all key details except the full specification of runtime behavior is finished. Feedback is appreciated!
We have a reference implementation implementation of the parser and tests of all the syntactic edge cases discussed in the PEP [2].
Implementing the runtime behavior will be challenging and there are open questions, so we have a separate doc for that [3].
Eventually we need to move some details of our runtime doc into the PEP itself but at this stage I find it helpful to keep them separate because there are more open questions about the API itself, names, and implementation details of the runtime than about the syntax itself and backward compatibility.
Cheers!
Steven Troxler
S Pradeep Kumar
---
[1] Draft PEP: https://docs.google.com/document/d/16UmBItZWIzKZK3ZTpDKH8vazNZ817E4UqKmPteb…
[2] Branch with the parser implementation: https://github.com/stroxler/cpython/tree/callable-type-syntax--shorthand
[3] Doc specifying the planned runtime behavior: https://docs.google.com/document/d/15nmTDA_39Lo-EULQQwdwYx_Q1IYX4dD5WPnHbFG…
Hello all,
Thank you for the comments on the Callable syntax PEP. We're pretty much
ready to get feedback on it from python-dev.
However, when I looked at some real-world snippets using the syntax, I had
some serious concerns about readability. Specifically, Python's function
signatures use `->` for the return type. This makes it somewhat hard for a
reader to distinguish between the `->` of a callback parameter and the `->`
of the return type. For example:
```py
def flat_map(l: list[int], func: (int) -> list[int]) -> list[int]:
def module_for_loader(fxn: (...) -> types.ModuleType) -> (...) ->
types.ModuleType: ...
```
I have to read them carefully to tell which one is the return type. Other
languages, such as TypeScript, don't have this ambiguity between callable
type arrow and function signature arrow because they use a colon for their
function signature return type:
```ts
function flat_map(xs: number[], f: (x: number) => number[]): number[] { }
```
So, we're leaning towards using `=>` for the Callable arrow, which readers
will probably find less ambiguous:
```py
def flat_map(l: list[int], func: (int) => list[int]) -> list[int]:
def module_for_loader(fxn: (...) => types.ModuleType) -> (...) =>
types.ModuleType: ...
```
To get a feel for how this will look in real-world code, I sampled 15
function signatures from typeshed and wrote them using both the dash-arrow
(->) and the equals-arrow (=>):
https://gist.github.com/pradeep90/bde2e0e278e4a84edb5db754f44c4531
What do you think? I know that this means it differs from the function
signature, but that may actually be a readability plus, not a minus. (In
any case, callable type syntax differs from function signatures - no
parameter names, etc.) The downside is that new users would have to learn
to use `=>`.
Any strong objections to using `=>`?
--
S Pradeep Kumar
Steven Troxler
The following is an overview of all issues and pull requests in the
typing repository on GitHub with the label 'topic: feature'
that were opened or updated last week, excluding closed issues.
---------------------------------------------------
The following issues and pull requests were updated last week:
#213 Introduce an Intersection
opened by @ilevkivskyi
https://github.com/python/typing/issues/213
#548 Higher-Kinded TypeVars
opened by @tek
https://github.com/python/typing/issues/548
---------------------------------------------------
All issues and pull requests with the label 'topic: feature'
can be viewed under the following URL:
https://github.com/python/typing/issues?q=label%3A%22topic%3A+feature%22
Hi all,
We'd provisionally scheduled our next tensor typing meeting for the 13th of
December, but I'm not sure we have anything to discuss this month.
In terms of progress updates from our end, Pradeep and I have been working
on making a small change to PEP 646 (peps/2162
<https://github.com/python/peps/pull/2162>) that arose from some new edge
cases we discovered around `*args: *Ts`, and also iterating on
grammar/compiler changes necessary to avoid a small problem pointed out to
us in the AST representation of `*args: *Ts` (typing/950
<https://github.com/python/typing/issues/950>).
Does anyone else have anything they'd like to talk about? Otherwise we'll
postpone our next meeting until after the new year.
Thanks!
Matthew
The following is an overview of all issues and pull requests in the
typing repository on GitHub with the label 'topic: feature'
that were opened or updated last week, excluding closed issues.
---------------------------------------------------
The following issues and pull requests were updated last week:
#213 Introduce an Intersection
opened by @ilevkivskyi
https://github.com/python/typing/issues/213
#922 non-final frozen attributes (was: Improved read-only attributes of Protocol)
opened by @ariebovenberg
https://github.com/python/typing/issues/922
#930 Request: an AssertingTypeGuard type for TypeGuard-like semantics
opened by @sirosen
https://github.com/python/typing/issues/930
---------------------------------------------------
All issues and pull requests with the label 'topic: feature'
can be viewed under the following URL:
https://github.com/python/typing/issues?q=label%3A%22topic%3A+feature%22
