Repository navigation
Change names of builtin types exposed in the types module #100129
Description
Some builtin types (like int, range, map) are exposed in the builtins module under their names. int.__name__ is "int" and int.__module__ is "builtins". getattr(sys.modules[int.__module__], int.__name__) is int
Other builtin types are exposed in the types module, but their __module__ attribute is still "builtins", and their __name__ attribute is different from the name under which they are accessible in the types module. The relation between names is not obvious, when you see <class 'builtin_function_or_method'>, it is hard to defer that it is types.BuiltinFunctionType.
As result, these types cannot be pickled:
>>> pickle.dumps(types.ClassMethodDescriptorType)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
_pickle.PicklingError: Can't pickle <class 'classmethod_descriptor'>: attribute lookup classmethod_descriptor on builtins failedI propose to change attributes __module__, __name__ and __qualname__ of all builtin types exposed in the types modules so that they will match names under which they are accessible.
Linked PRs
- gh-100129: Make the names of all classes in the types module resolvable #100130
- gh-100129: Add tests for pickling all builtin types and functions #100142
- [3.11] gh-100129: Add tests for pickling all builtin types and functions (GH-100142) #100405
- [3.10] gh-100129: Add tests for pickling all builtin types and functions (GH-100142) #100406
Activity
pythongh-100129: Make the names of all classes in the types module re…
vstinner commentedon Dec 9, 2022
It sounds like a good idea.
Changing names like builtin_function_or_method will impact doctests, but I think that it's worth it.
AlexWaygood commentedon Dec 9, 2022
+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.
serhiy-storchaka commentedon Dec 9, 2022
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.
markshannon commentedon Dec 9, 2022
Changing 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.
pythongh-100129: Add tests for pickling all builtin types and functions
serhiy-storchaka commentedon Dec 21, 2022
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?gh-100129: Add tests for pickling all builtin types and functions (GH…
pythongh-100129: Add tests for pickling all builtin types and functio…
pythongh-100129: Add tests for pickling all builtin types and functio…
gh-100129: Add tests for pickling all builtin types and functions (GH…
gh-100129: Add tests for pickling all builtin types and functions (GH…
Merged main into regmachine branch (#50)
jamesbraza commentedon Jun 28, 2023
Hello all, just chiming in on this. I think the core of this issue is:
types, and break users who depended on prior naming special casestypesunstandardized, and require all new users to implement special casesJust to share my "user story":
typesbeing nonstandard today, when doing deserialization based on__module__/__qualname__traceback, when the docs say it should betypes.TracebackTypeI think generally removing unexpected confusion for future users is a worthwhile benefit of #100130