Closed maxfischer2781 closed 4 years ago
As it turns out, typing.Callable
is absolutely not like typing.Generic
at all. Representing the former with the latter is a hack one way or another.
I've added an explicit Callable
IR type, which vastly simplifies handling (i.e. normalize and unparse). We should already cover all valid Callable
forms as steno types:
$ venv/bin/stenotype '(*_) -> R'
typing.Callable[..., R]
$ venv/bin/stenotype '(A, B, C) -> R'
typing.Callable[[A, B, C], R]
$ venv/bin/stenotype '(A, B, /, C) -> R'
typing.Callable[[A, B, C], R]
Note that we cannot parse Callable[..., R]
and Callable[[A, B, C], R]
yet. However, this should be doable due to typing.Callable
being absolutely not like typing.Generic
at all.
This PR adds support for
(A) -> R
callable syntax. Changes include:Callable
,Parameter
andSignature
representations to IR,(A, ...) -> R
style steno types matching Python 3.8,(...) -> R
special case,Callable
cases with.backend.typing.normalize
,Callable
types,The grammar and IR represents the entire Python 3.8 call grammar. This far exceeds what
typing.Callable
can represent, and will require #29 (or similar) to emit again. Since there is no distinction betweenCallable
andProtocol
in stenotype syntax itself, implementing a single IR/grammar straight away seemed less hacky.