red-knot: infer and display ellipsis type#13124
red-knot: infer and display ellipsis type#13124AlexWaygood merged 3 commits intoastral-sh:mainfrom chriskrycho:rk-ellipsis-type
Conversation
|
AlexWaygood
left a comment
There was a problem hiding this comment.
Hmm, not sure about this approach
| Type::EllipsisType => { | ||
| // TODO: attribute lookup on Ellipsis type | ||
| Type::Unknown | ||
| } |
There was a problem hiding this comment.
I'm not sure this needs to be its own variant in the Type enum... it's conceptually just an instance of types.EllipsisType. types.EllipsisType was only exposed on Python 3.10+, but typeshed already provides a nice little compatibility workaround for us here: https://github.com/python/typeshed/blob/f58dac1d62d33bb2255b762783d06463c40f5065/stdlib/builtins.pyi#L1849-L1865
(builtins.Ellipsis is the same object as ...)
>>> ...
Ellipsis
>>> Ellipsis
Ellipsis
>>> Ellipsis is ...
TrueThere was a problem hiding this comment.
One interesting way in which ... is special is that it's a singleton: it is the only instance of types.EllipsisType that there is, or that there could be. But that can be thought of as just a sealed type that has exactly one member, and we've yet to implement a generalised way of handling sealed types. (We'll need them to tackle enums in Python!) See https://github.com/astral-sh/ruff/issues/12694.
Defer to the built-in type and leave notes about where and how we ought to be resolving to `typing.EllipsisType` instead of the current output, which is `Unknown | Literal[EllipsisType]`.
Summary
Just what it says on the tin: adds basic
EllipsisTypeinference for any time...appears in the AST.Test Plan
Test that
x = ...produces exactly what we would expect.