Consider reintroducing `types.EllipsisType` for the sake of typing

[BvB93]

BPO	41810
Nosy	@gvanrossum, @rhettinger, @ericvsmith, @markshannon, @serhiy-storchaka, @ilevkivskyi, @SamuelMarks, @BvB93, @joshbode
PRs	bpo-41810: Reintroduce types.EllipsisType, .NoneType & .NotImplementedType #22336

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2020-09-22.15:55:57.057>
created_at = <Date 2020-09-18.19:29:00.494>
labels = ['type-feature', 'library', '3.10']
title = 'Consider reintroducing `types.EllipsisType` for the sake of typing'
updated_at = <Date 2020-11-05.09:51:11.541>
user = 'https://github.com/BvB93'

bugs.python.org fields:

activity = <Date 2020-11-05.09:51:11.541>
actor = 'eric.smith'
assignee = 'none'
closed = True
closed_date = <Date 2020-09-22.15:55:57.057>
closer = 'gvanrossum'
components = ['Library (Lib)']
creation = <Date 2020-09-18.19:29:00.494>
creator = 'BvB93'
dependencies = []
files = []
hgrepos = []
issue_num = 41810
keywords = ['patch']
message_count = 22.0
messages = ['377135', '377154', '377165', '377167', '377169', '377178', '377248', '377250', '377255', '377259', '377264', '377267', '377269', '377274', '377275', '377277', '377280', '377281', '377282', '377340', '380400', '380401']
nosy_count = 9.0
nosy_names = ['gvanrossum', 'rhettinger', 'eric.smith', 'Mark.Shannon', 'serhiy.storchaka', 'levkivskyi', 'samuelmarks', 'BvB93', 'joshbode']
pr_nums = ['22336']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue41810'
versions = ['Python 3.10']

[BvB93]

Ellipsis is one of the few builtin objects whose type is not exposed via the types module.
This is not really an issue during runtime, as you can always call type(Ellipsis), but for the purpose of typing it is detrimental; the lack of suitable type means that it is impossible to properly annotate a function which takes or returns Ellipsis (unless one is willing to resort to the use of non-public types: python/typeshed#3556).

In order to resolve this issue I propose to reintroduce types.EllipsisType. This should be a fairly simple process, so if there are no objections I'd be willing to give it a shot.

[serhiy-storchaka]

Can not type(Ellipsis) be used for typing too?

[BvB93]

If you're asking whether or not one can infer the return type of type(Ellipsis) then yes.
In such case the inferred type is builtins.ellipsis, which is a private stub-only class (see the referenced typeshed issue in my original post).

If you're asking if a valid annotation can be constructed from type(Ellipsis) then the answer is unfortunately no (see below for a few examples).

EllipsisType = type(Ellipsis)

# Both examples are considered invalid
def func1(a: type(Ellipsis): ...
def func2(a: EllipsisType): ...

[gvanrossum]

Let’s do this.

[serhiy-storchaka]

Would not be better to make MyPy supporting type(Ellipsis)? It would work also on Python versions older than 3.10.

Also, could not Literal[Ellipsis] be used as annotation?

[gvanrossum]

Would not be better to make MyPy supporting type(Ellipsis)? It would work also on Python versions older than 3.10.

That would be quite complicated. There is no place in annotations where a function call is currently supported, so I'd prefer not to go there.

Also, could not Literal[Ellipsis] be used as annotation?

Alas, it currently doesn't work (PEP-586 only allows specific types, and type checkers have implemented it exactly). Making it work would be more complicated than the proposal -- once it exists in types.py, it's trivial to add support to mypy.

IMO ideally, eventually, all "hidden" built-in types ought to be exposed somewhere, unless they are truly implementation details -- but since Ellipsis is a first-class singleton object, I don't see how its type could be an implementation detail. (Its name is actually clearly visible in repr(type(Ellipsis)).)

Note that we have started exporting the types of other constructs through types.py, e.g. type(int|str) is types.Union, and type(list[str]) is types.GenericAlias. This is revealed in their repr().

[BvB93]

If we're going ahead with this: PR #22336 contains a concrete implementation of the proposed changes.

[markshannon]

I can't resist the pun on typing.
type(...) is the least typing :)

More seriously,

From a general consistency point of view,
if this is to be added, shouldn't types.NoneType and types.NotImplementedType be added as well?

[gvanrossum]

I’m okay with adding those (even though NoneType might not work in mypy, given the special-casing for None, per PEP-484).