[red-knot] Allow CallableTypeFromFunction to display the signatures of callable types that are not function literals#17047
Conversation
… of callable types that are not function literals
|
carljm
left a comment
carljm
left a comment
There was a problem hiding this comment.
This looks good to me! I would probably rename to CallableTypeOf?
|
Renamed it to |
| # TODO: `self` is bound here; this should probably be `(x: int) -> str`? | ||
| reveal_type(c5) # revealed: (self, x: int) -> str |
There was a problem hiding this comment.
Should c5 be stored as (x: int) -> str, or stored as (self, x: int) -> str and treated like (x: int) -> str?
There was a problem hiding this comment.
Not entirely sure! I think this requires deeper exploration. Today we do the latter. There are a couple interesting questions that it connects to:
-
How do we handle equivalent callable types? If we aim for "equivalent callable types are always the same Salsa ID" then it should actually be stored as
(x: int) -> str. But I don't think it's totally clear yet if that will be feasible. -
When do we issue an error on calling a bound method with an annotation on the
selfargument that doesn't match the instance we accessed it from? Does it happen when accessing the bound method, or when calling it? The latter seems better (matches runtime better), but requires storing the bound self type and the full signature.
It seems likely that we need to support both representations and understand their equivalence. (But maybe our "general callable type" uses only the simpler representation?)
4 participants
I found this helpful for understanding some of the stuff that was going on in #17005. It means the name of the special form is perhaps no longer ideal; I could possibly rename it if we agree that this is a useful feature.