> It would be nice if someone did some work and collected a list of tutorials
> about type annotations that exist (especially the ones that are discoverable
> with a simple Bing query) and ranked them by quality.
I went with Google rather than Bing but here's what I found:
I've been wondering whether it would make sense to have a function in `inspect`
that returns the signature of a type, rather than the signature of a specific
callable object.
I'm not attached to any name for such a function, two ideas are
`inspect.signature_of` or `inspect.signature_of_type`.
We just merged changes to the PEP with a detailed runtime API specification.
Highlights are that:
- The new type should have an `inspect.Signature`- inspired structured API
- It should have a backward-compatible interface with the `__args__` and
`__params__`
- As with the PEP 604 union syntax,
Using an operator is an interesting idea, and we should probably call it out as
an alternative in the PEP.
It's not a substitute for the current PEP from the standpoint of typing-sig for
a few reasons:
(A) We care that the syntax be forward-compatible with supporting named
arguments, as
Good catch, thanks Nick!
It's been specified in a linked doc [0] but I forgot to move that into the PEP
itself.
I'll aim to get that done today.
---
[0]
https://docs.google.com/document/d/15nmTDA_39Lo-EULQQwdwYx_Q1IYX4dD5WPnHbFG71Lk/edit
___
Python-Dev
Hello all,
We’d like to make a last call for discussion on PEP 677: Callable Type Syntax
[1] before sending this to the Steering Council.
For context, PEP 677 proposes an arrow-like callable syntax for python:
```
(int, str) -> bool # equivalent to Callable[[int, str], bool]
```
Thanks
In the example I was aiming for something easy to understand that produced a
type illustrating potential problems of PEP 677, which is at its worst when
there are callables in both argument and return position. I don't have a great
real-world example of this worst-case, most of what I've seen
I've been thinking about readability hard because I share many of your concerns
about readability.
I'm starting to think parenthesizing the outside might work much better in
practice:
```
(int, str -> bool)
```
instead of
```
(int, str) -> bool
```
This looks a bit less familiar, but it
-
In most of our discussions of this idea, we've assumed that we'd adopt the same
semantics that callback protocols use.
If we do that, then only `lambda a: 3` will type check. In order to type check
both you'd have to make `a` positional-only:
```
def IntToIntFunc(a: int, /) -> int:
...
```
Thanks for the feedback. I have a few thoughts.
(1) Concerns about complexity of the syntax make sense to me, it's definitely
possible to write confusing types with this syntax. Readability would be a good
reason to reject this idea, but it does cut both ways because `Callable` can be
hard to
ils
and edge cases we need to consider regarding runtime behavior.
Cheers,
Steven Troxler
-
[1] Earlier python-dev thread
https://mail.python.org/archives/list/python-dev@python.org/thread/VBHJOS3LOXGVU6I4FABM6DKHH65GGCUB/
[2] PEP 677: https://www.python.org/dev/peps/pep-0677/
[3] Refere
> Is this also why re-using an actual callable at a type was rejected?
The idea to use a function as a type (which Łukasz proposed at the PyCon typing
summit) is still under consideration. Our thought was that it would probably be
a separate PEP from a syntax change.
Personally, I think we
We drew up a draft syntax to clarify the three styles that have been discussed
in typing-sig:
- shorthand syntax, which supports exactly what Callable currently supports
- XOR syntax, which would allow a def-like style in addition to shorthand
- hybrid syntax, which extends shorthand to support
13 matches
Mail list logo
