[issue41810] Consider reintroducing `types.EllipsisType` for the sake of typing

Eric V. Smith added the comment: I don't think we should backport them. It's definitely a new feature, and our policy is no new features in micro versions. -- ___ Python tracker

[issue41810] Consider reintroducing `types.EllipsisType` for the sake of typing

Samuel Marks added the comment: Since we're bringing these back, would you accept a backport of these types? [I'm writing a bunch of parsers/emitters—and starting to maintain an old runtime type-checker—for 3.6+] -- nosy: +samuelmarks ___ Python

[issue41810] Consider reintroducing `types.EllipsisType` for the sake of typing

Guido van Rossum added the comment: New changeset 0d0e9fe2ffc1683758a1985ef6dedeef5ecafdbc by Bas van Beek in branch 'master': bpo-41810: Reintroduce `types.EllipsisType`, `.NoneType` & `.NotImplementedType` (GH-22336)

[issue41810] Consider reintroducing `types.EllipsisType` for the sake of typing

Change by Guido van Rossum : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue41810] Consider reintroducing `types.EllipsisType` for the sake of typing

Raymond Hettinger added the comment: > Do any of the other deleted types strike you as possibly > needing to come back? Yes. NoneType would be useful. -- nosy: +rhettinger ___ Python tracker

[issue41810] Consider reintroducing `types.EllipsisType` for the sake of typing

Eric V. Smith added the comment: Thanks for doing the research, Bas! It sounds like adding back in NoneType, NotImplementedType, and EllipsisType is appropriate, then. +1 The commit should have a comment about the reason: for type checkers which can't use type(Ellipsis), etc. I'll add a

[issue41810] Consider reintroducing `types.EllipsisType` for the sake of typing

Bas van Beek added the comment: > Do any of the other deleted types strike you as possibly needing to come back? I don't think so, no. The only other one that stands out to me is `DictProxyType`, which has already been reintroduced as `MappingProxyType`. --

[issue41810] Consider reintroducing `types.EllipsisType` for the sake of typing

Guido van Rossum added the comment: Thanks! Most of the deleted types *are* builtins (e.g. object, int). I assume the reasoning was just that if you wanted the type you could just write type(Ellipsis), type(None) etc. But that's too dynamic for static checkers, so we want *some* stable name

[issue41810] Consider reintroducing `types.EllipsisType` for the sake of typing

Bas van Beek added the comment: According to the relevant commit (https://github.com/python/cpython/commit/c9543e42330e5f339d6419eba6a8c5a61a39aeca): "Removed all types from the 'types' module that are easily accessible through builtins." -- ___

[issue41810] Consider reintroducing `types.EllipsisType` for the sake of typing

Guido van Rossum added the comment: Bas can you do some research to answer Eric's question? In theory it should be possible to use git bisect to find it. I see it in 2.7 but not in 3.4. That's a fairly large interval, alas. -- ___ Python tracker

[issue41810] Consider reintroducing `types.EllipsisType` for the sake of typing

Eric V. Smith added the comment: Does anyone know why types.EllipsisType was removed to begin with? I just want to make sure we're not repeating some mistake of the past. -- nosy: +eric.smith ___ Python tracker

[issue41810] Consider reintroducing `types.EllipsisType` for the sake of typing

Bas van Beek added the comment: `NoneType` and `NotImplementedType` have been added to the PR as of the latest set of pushes. -- ___ Python tracker ___

[issue41810] Consider reintroducing `types.EllipsisType` for the sake of typing

Guido van Rossum added the comment: > In any case, I'm ok with adding `NoneType` and `NotImplementedType` to the PR. Please do. -- ___ Python tracker ___

[issue41810] Consider reintroducing `types.EllipsisType` for the sake of typing

Bas van Beek added the comment: Apparently pyright has some interest in `NoneType` (https://github.com/python/typeshed/pull/4519), so it seems there are already some actual use cases. In any case, I'm ok with adding `NoneType` and `NotImplementedType` to the PR. --

[issue41810] Consider reintroducing `types.EllipsisType` for the sake of typing

Guido van Rossum added the comment: I’m okay with adding those (even though NoneType might not work in mypy, given the special-casing for None, per PEP 484). -- ___ Python tracker

[issue41810] Consider reintroducing `types.EllipsisType` for the sake of typing

Mark Shannon added the comment: 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? -- nosy: +Mark.Shannon

[issue41810] Consider reintroducing `types.EllipsisType` for the sake of typing

Bas van Beek added the comment: If we're going ahead with this: PR https://github.com/python/cpython/pull/22336 contains a concrete implementation of the proposed changes. -- ___ Python tracker

[issue41810] Consider reintroducing `types.EllipsisType` for the sake of typing

Change by Bas van Beek : -- keywords: +patch pull_requests: +21381 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22336 ___ Python tracker ___

[issue41810] Consider reintroducing `types.EllipsisType` for the sake of typing

Guido van Rossum added the comment: > 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

[issue41810] Consider reintroducing `types.EllipsisType` for the sake of typing

Serhiy Storchaka added the comment: 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? -- ___ Python tracker

[issue41810] Consider reintroducing `types.EllipsisType` for the sake of typing

Guido van Rossum added the comment: Let’s do this. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41810] Consider reintroducing `types.EllipsisType` for the sake of typing

Bas van Beek added the comment: 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

[issue41810] Consider reintroducing `types.EllipsisType` for the sake of typing

Serhiy Storchaka added the comment: Can not `type(Ellipsis)` be used for typing too? -- nosy: +gvanrossum, levkivskyi, serhiy.storchaka ___ Python tracker ___

[issue41810] Consider reintroducing `types.EllipsisType` for the sake of typing

Change by Josh Bode : -- nosy: +joshbode ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41810] Consider reintroducing `types.EllipsisType` for the sake of typing

New submission from Bas van Beek : `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