◐ Shell
reader mode source ↗
Skip to content

gh-100129: Make the names of all classes in the types module resolvable#100130

Open
serhiy-storchaka wants to merge 11 commits into
python:mainfrom
serhiy-storchaka:types-qualnames
Open

gh-100129: Make the names of all classes in the types module resolvable#100130
serhiy-storchaka wants to merge 11 commits into
python:mainfrom
serhiy-storchaka:types-qualnames

Conversation

@serhiy-storchaka

@serhiy-storchaka serhiy-storchaka commented Dec 9, 2022 •
edited by bedevere-bot
Loading

Copy link
Copy Markdown
Member

@bedevere-bot bedevere-bot mentioned this pull request Dec 9, 2022
Open
@serhiy-storchaka serhiy-storchaka marked this pull request as ready for review December 9, 2022 17:36
@python python deleted a comment from netlify Bot Dec 10, 2022
JelleZijlstra
JelleZijlstra reviewed Dec 20, 2022
View reviewed changes

@JelleZijlstra JelleZijlstra left a comment

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.

Hide comment

I like how this change makes the builtin types more consistent and easy to resolve. However, I have two concerns:

  • When the new type names appear in error messages, they make the errors harder to understand for new users. This is especially important with core types like module, function, and None.
  • We'll surely break some external tools that rely on the names of these classes.

I think the case for changing is strongest for the various descriptor types, where it's otherwise difficult right now to map a type to the entry in the types module, and weakest for core builtins like module, function, and NoneType.

@AlexWaygood

AlexWaygood commented Dec 20, 2022

Copy link
Copy Markdown
Member

I think the case for changing is strongest for the various descriptor types, where it's otherwise difficult right now to map a type to the entry in the types module, and weakest for core builtins like module, function, and NoneType.

Agreed. I'm broadly supportive of this change, but the change to None in particular makes me feel pretty queasy.

gvanrossum
gvanrossum approved these changes Dec 21, 2022
View reviewed changes

@gvanrossum gvanrossum left a comment

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.

Hide comment

I have a few nits -- feel free to address or ignore those.

I'd like @JelleZijlstra or another typeshed/mypy dev to have a quick look here to see whether changing a few names like function, ellipsis would cause any issues for static type checkers (though I doubt it).

@JelleZijlstra

JelleZijlstra commented Dec 21, 2022

Copy link
Copy Markdown
Member

I'd like @JelleZijlstra or another typeshed/mypy dev to have a quick look here to see whether changing a few names like function, ellipsis would cause any issues for static type checkers (though I doubt it).

Fully static type checkers like mypy never look at the runtime type objects so it shouldn't matter. Tools like stubtest or my pyanalyze typechecker might need to adapt a little but that's pretty easy.

@gvanrossum

gvanrossum commented Dec 21, 2022

Copy link
Copy Markdown
Member

Fully static type checkers like mypy never look at the runtime type objects so it shouldn't matter. Tools like stubtest or my pyanalyze typechecker might need to adapt a little but that's pretty easy.

I was thinking about it slightly differently. Typeshed defines classes builtins.function and builtins.ellipsis (and maybe others). Those were always a typeshed-only fiction, but mypy does recognize it -- e.g. this program shows no errors:

def f():
    pass

func: function = f

There was some precedent for this when type(f) would return <class 'function'> at runtime. But the new regime would suggest that instead the variable func above should be typed as

import types
func: types.FunctionType = f

which currently produces an error in mypy.

(In a sense, this PR finally resolves a problem that mypy experienced from its creation: what is the name of the type of a function object. Grepping shows dozens of occurrences of builtins.function in the mypy source code.)

I agree that we shouldn't stop this PR because it exposes mypy's "lie". :-)

@gvanrossum

gvanrossum commented Dec 21, 2022

Copy link
Copy Markdown
Member

Thanks for the answers, go ahead and merge.

@serhiy-storchaka

serhiy-storchaka commented Dec 21, 2022

Copy link
Copy Markdown
Member Author

What do you think about omitting the "types." prefix like the "builtins." prefix and, in some cases, the "__main__." prefix, in error messages and type reprs?

@markshannon

markshannon commented Dec 21, 2022

Copy link
Copy Markdown
Member

This is going to break things. Changing the names NoneType, the type of generators and functions is going to break someone's code. Maybe they shouldn't be relying on those names and those are acceptable breakages, but I think we should take a bit more care here.

There are a lot of changes to the tests. If this change breaks our tests, it is reasonable to assume it will break other people's tests.

@gvanrossum

gvanrossum commented Dec 21, 2022

Copy link
Copy Markdown
Member

I'm happy to retract my approval in favor of more discussion -- maybe we should do that on Discourse though, where we can get the view of more people whose code actually will break. I agree that the amount of change needed in our own tests doesn't bode well.

@AlexWaygood AlexWaygood removed their request for review February 3, 2023 10:12
@tungol

tungol commented Nov 11, 2024

Copy link
Copy Markdown
Contributor

Just to note: the new-in-3.13 types.CapsuleType / PyCapsule is not included in the current state of this MR, and should also be updated if this gets picked up again.

@github-actions

github-actions Bot commented Apr 11, 2026

Copy link
Copy Markdown

This PR is stale because it has been open for 30 days with no activity.

@github-actions github-actions Bot added the stale Stale PR or inactive for long period of time. label Apr 11, 2026
@read-the-docs-community

read-the-docs-community Bot commented Jun 4, 2026 •
edited
Loading

Copy link
Copy Markdown

Documentation build overview

📚 cpython-previews | 🛠️ Build #32994241 | 📁 Comparing f74b4b2 against main (038495d)

  🔍 Preview build  

8 files changed · ± 8 modified

± Modified

@brettcannon brettcannon removed their request for review June 4, 2026 18:00
@github-actions github-actions Bot removed the stale Stale PR or inactive for long period of time. label Jun 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@JelleZijlstra JelleZijlstra JelleZijlstra left review comments

@erlend-aasland erlend-aasland erlend-aasland left review comments

@gvanrossum gvanrossum gvanrossum approved these changes

@Fidget-Spinner Fidget-Spinner Awaiting requested review from Fidget-Spinner

@iritkatriel iritkatriel Awaiting requested review from iritkatriel iritkatriel is a code owner

@markshannon markshannon Awaiting requested review from markshannon markshannon is a code owner

@rhettinger rhettinger Awaiting requested review from rhettinger rhettinger is a code owner

@tiran tiran Awaiting requested review from tiran

@AA-Turner AA-Turner Awaiting requested review from AA-Turner AA-Turner is a code owner

@pablogsal pablogsal Awaiting requested review from pablogsal pablogsal is a code owner

@lysnikolaou lysnikolaou Awaiting requested review from lysnikolaou lysnikolaou is a code owner

@ambv ambv Awaiting requested review from ambv ambv is a code owner

@gaogaotiantian gaogaotiantian Awaiting requested review from gaogaotiantian gaogaotiantian is a code owner

@gpshead gpshead Awaiting requested review from gpshead gpshead is a code owner

@ericsnowcurrently ericsnowcurrently Awaiting requested review from ericsnowcurrently ericsnowcurrently is a code owner

@Yhg1s Yhg1s Awaiting requested review from Yhg1s Yhg1s is a code owner

@DinoV DinoV Awaiting requested review from DinoV DinoV is a code owner

@ncoghlan ncoghlan Awaiting requested review from ncoghlan ncoghlan is a code owner

@warsaw warsaw Awaiting requested review from warsaw warsaw is a code owner

@FFY00 FFY00 Awaiting requested review from FFY00 FFY00 is a code owner

@ZeroIntensity ZeroIntensity Awaiting requested review from ZeroIntensity ZeroIntensity is a code owner

@savannahostrowski savannahostrowski savannahostrowski is a code owner

Assignees

No one assigned

Labels

awaiting merge

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

8 participants

@serhiy-storchaka @AlexWaygood @JelleZijlstra @gvanrossum @markshannon @tungol @erlend-aasland @bedevere-bot