Repository navigation
Change names of builtin types exposed in the types module #100129
Description
Activity
It sounds like a good idea.
Changing names like builtin_function_or_method will impact doctests, but I think that it's worth it.
+1 to this idea. This will make life easier for tools that do dynamic inspection of Python at runtime. The current situation makes life difficult at times for, e.g., mypy's stubtest tool.
I proposed this idea several years ago, and perhaps even an issue was created (but I cannot find it now). Guido was positive about this, but I had some doubts. The original code was written in 2018, now I'm going to finish it.
Reacted by Alex WaygoodChanging the names of common types like
NoneTypeandgeneratoris going to break a lot of stuff.
The number of test changes required for the PR suggests that this would cause widespread breakage.There must be other ways to make these objects pickleable.
Yes, it will break some doctests. The main purpose of this change is not making these types pickleable (a special case was already added for
NoneType,EllipsisTypeandNotImplementedType, and it can be extended for other types), but making them more uniform with other types.The breakage of doctests can be reduced if we omit the module name in repr and error messages if
__module__ == "types". Currently it is omitted for"builtins", and, in some cases, for"__main__", we can add a special case for"types". It is not a simple change, because it will require to make changes in several places. What do you think about this?- added a commit that references this issue
on Dec 21, 2022 - added 4 commits that reference this issue
on Dec 21, 2022 - added a commit that references this issue
on Dec 28, 2022 Hello all, just chiming in on this. I think the core of this issue is:
- Standardize
types, and break users who depended on prior naming special cases- Note: naming special cases don't 1-1 correspond with Python docs
- Leave
typesunstandardized, and require all new users to implement special cases
Just to share my "user story":
- I got bit by
typesbeing nonstandard today, when doing deserialization based on__module__/__qualname__ - I have been confused about types being shown as
traceback, when the docs say it should betypes.TracebackType
I think generally removing unexpected confusion for future users is a worthwhile benefit of #100130
- Standardize
- marked types.FunctionType is not included in builtin library #92316 as a duplicate of this issue
on Jun 2, 2026
Some builtin types (like
int,range,map) are exposed in thebuiltinsmodule under their names.int.__name__is "int" andint.__module__is "builtins".getattr(sys.modules[int.__module__], int.__name__) is intOther builtin types are exposed in the
typesmodule, but their__module__attribute is still "builtins", and their__name__attribute is different from the name under which they are accessible in thetypesmodule. The relation between names is not obvious, when you see<class 'builtin_function_or_method'>, it is hard to defer that it istypes.BuiltinFunctionType.As result, these types cannot be pickled:
I propose to change attributes
__module__,__name__and__qualname__of all builtin types exposed in thetypesmodules so that they will match names under which they are accessible.Linked PRs