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

[Eric V. Smith]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Samuel Marks]

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 tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Guido van Rossum]

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)
https://github.com/python/cpython/commit/0d0e9fe2ffc1683758a1985ef6dedeef5ecafdbc


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Guido van Rossum]

Change by Guido van Rossum :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Eric V. Smith]

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 comment on the PR about adding a 
similar note to the blurb.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Bas van Beek]

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`.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Guido van Rossum]

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 for 
those back. Do any of the other deleted types strike you as possibly needing to 
come back?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Bas van Beek]

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."

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Guido van Rossum]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Eric V. Smith]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Bas van Beek]

Bas van Beek  added the comment:

`NoneType` and `NotImplementedType` have been added to the PR as of the latest 
set of pushes.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Guido van Rossum]

Guido van Rossum  added the comment:

> In any case, I'm ok with adding `NoneType` and `NotImplementedType` to the PR.

Please do.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Bas van Beek]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Guido van Rossum]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Shannon]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Bas van Beek]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Bas van Beek]

Change by Bas van Beek :


--
keywords: +patch
pull_requests: +21381
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/22336

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Guido van Rossum]

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 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().

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Guido van Rossum]

Guido van Rossum  added the comment:

Let’s do this.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Bas van Beek]

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 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): ...

```

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

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

--
nosy: +gvanrossum, levkivskyi, serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Josh Bode]

Change by Josh Bode :


--
nosy: +joshbode

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Bas van Beek]

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 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: https://github.com/python/typeshed/issues/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.

--
components: Library (Lib)
messages: 377135
nosy: BvB93
priority: normal
severity: normal
status: open
title: Consider reintroducing `types.EllipsisType` for the sake of typing
type: enhancement
versions: Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com