GeezerVison is showing github.com — Change names of builtin types exposed in the types module · Issue #100129 · python/cpython
Change names of builtin types exposed in the types module #100129DescriptionSome 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 failed I 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
Reacted by Alex Waygood, James Braza and Rafal Krupinski Activityvstinner commented on 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 commented on 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 commented on 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 commented on Dec 9, 2022 Changing the names of common types like NoneType and generator is 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. serhiy-storchaka commented on 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, EllipsisType and NotImplementedType, 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 4 commits that reference this issue on Dec 21, 2022gh-100129: Add tests for pickling all builtin types and functions (GH… gh-100129: Add tests for pickling all builtin types and functions (GH… jamesbraza commented on Jun 28, 2023 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
types unstandardized, and require all new users to implement special cases
Just to share my "user story":
- I got bit by
types being 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 be types.TracebackType
I think generally removing unexpected confusion for future users is a worthwhile benefit of #100130
MetadataMetadataStatusShow more project fields
DevelopmentNo branches or pull requestsIssue actions
|