Skip to content

Replace builtins.ellipsis with types.EllipsisType - #21911

Merged
JelleZijlstra merged 1 commit into
python:masterfrom
hamdanal:ellipsis
Aug 29, 2026
Merged

Replace builtins.ellipsis with types.EllipsisType#21911
JelleZijlstra merged 1 commit into
python:masterfrom
hamdanal:ellipsis

Conversation

@hamdanal

@hamdanal hamdanal commented Aug 29, 2026

Copy link
Copy Markdown
Collaborator

Part of #8240

Unblocks python/typeshed#15712

The actual change is one line in checkexpr and the other changes are for tests, mostly mechanical.
I used the try except trick used for types.ModuleType in the name lookup so that tests that don't import the types module don't crash with KeyError when they use ... (which is used in almost all tests as empty function body).

Most test changes are caused by modules now correctly resolving to module type instead of object because some fixtures started importing types.

The changes are mine, I only used a coding agent to fix the fine-grained-modules.test and testexportjson.py tests and the missing visitor method.

@github-actions

Copy link
Copy Markdown
Contributor

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

Comment thread mypy/test/teststubtest.py
"""

stubtest_builtins_stub = """
import types

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need the import?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because in test_enum there is a test that depends on the precise type of ... (because ... is special in stubs of enum subclasses) and the fallback we have for types.EllipsisType tests doesn't work for this test.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this just a test oddity? I guess in real code types will always be imported because builtins.pyi imports it.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, just test shenanigans. types will always be imported when using real typeshed because builtins.pyi imports it as you said.

@@ -1,3 +1,4 @@
import types

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it slow down test execution if more fixtures now need to analyze the types module?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't notice any slowdown locally or in CI (see timings in https://github.com/python/mypy/actions). The types module fixture is light-weightish anyway and we will need it in the near future when we replace builtins.function with types.FunctionType anyway.


a = (a.A(), A())
a.x # E: "tuple[a.A, b.A]" has no attribute "x"
a = (a.A(), A()) # E: Incompatible types in assignment (expression has type "tuple[a.A, b.A]", variable has type Module)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does this change?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TLDR; because import a on line 2 makes a an instance of types.ModuleType, not the object stub fallback as before because of import types in the fixture.

More explanation:
Before, a had type object which was narrowed to tuple on assignment as tuple it is a subtype of object, now mypy sees conflicting types.ModuleType and tuple types instead. This is OK here because the test is about types with the same name but defined in different modules. The goal is still achieved because we can still see "tuple[a.A, b.A]" in the error message.

The same reason applies to all object -> module changes as I mentioned in the opening message.

@JelleZijlstra
JelleZijlstra merged commit 6934a9d into python:master Aug 29, 2026
25 checks passed
@hamdanal
hamdanal deleted the ellipsis branch August 29, 2026 16:47
注册 for free to join this conversation on GitHub. Already have an account? 登录 to comment

标签

None yet

项目

None yet

Development

Successfully merging this pull request may close these issues.

2 participants