What about adding `EllipsisType` to the `types` std lib? This is how we handle types for modules and so on.
On the other hand, I'm not sure if Ellipsis counts as an "interpreter type" like the rest of the `types` lib. It seems closer to None, in the sense that it's a singleton, as you said.

Also, shouldn't `...` and `Ellipsis` be equivalent? My understanding is that they are synonyms, so I'm surprised that mypy doesn't treat them the same.

-- Teddy

On Wed, Mar 10, 2021 at 11:37 AM <henryfs@princeton.edu> wrote:
Currently, there's no PEP 484 way to type an Ellipsis, making it hard to add type checking to getitem/setitem. Type checkers (like MyPy, and it appears PyType) have supported "ellipsis" (as a string) as a stand-in for the missing type. This breaks linters like pyflakes, which expect "ellipsis" to be imported from somewhere even when it's a string, since it's not a builtin. (It MyPy's case, it also doesn't participate in narrowing, for some reason). It's also very difficult to discover.

It seems the most user-friendly solution would be to add a special case for Ellipsis, just like there is one for None (and NotImplemented might be due such a special case, too, based on the original thread from last year which I hope is linked in here). MyPy clearly differentiates between "..." and "Ellipsis" now; tuple[int, Ellipsis] does not work as a stand-in for tuple[int, ...]. Like None, there is only one Ellipsis, and it does not have an accessible base type.

If there's a problem with that solution, then adding "ellipsis" to typing would be a second possible solution. Then the name is correctly importable, and a bit more discoverable than a type-checker-only name. But IMO this should only be used if absolutely impossible to implement the first solution.

See also the issue in pyflakes: https://github.com/PyCQA/pyflakes/issues/616 with a couple of examples.
Typing-sig mailing list -- typing-sig@python.org
To unsubscribe send an email to typing-sig-leave@python.org
Member address: tsudol@google.com