Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change names of builtin types exposed in the types module #100129

Open
serhiy-storchaka opened this issue Dec 9, 2022 · 5 comments
Open

Change names of builtin types exposed in the types module #100129

serhiy-storchaka opened this issue Dec 9, 2022 · 5 comments
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement

Comments

@serhiy-storchaka
Copy link
Member

serhiy-storchaka commented Dec 9, 2022

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 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

@serhiy-storchaka serhiy-storchaka added type-feature A feature request or enhancement interpreter-core (Objects, Python, Grammar, and Parser dirs) labels Dec 9, 2022
serhiy-storchaka added a commit to serhiy-storchaka/cpython that referenced this issue Dec 9, 2022
@vstinner
Copy link
Member

vstinner commented 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
Copy link
Member

AlexWaygood commented 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
Copy link
Member Author

serhiy-storchaka commented 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
Copy link
Member

markshannon commented 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
Copy link
Member Author

serhiy-storchaka commented 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?

miss-islington pushed a commit to miss-islington/cpython that referenced this issue Dec 21, 2022
…ns (pythonGH-100142)

(cherry picked from commit b98d2d3)

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Dec 21, 2022
…ns (pythonGH-100142)

(cherry picked from commit b98d2d3)

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
miss-islington added a commit that referenced this issue Dec 21, 2022
…-100142)

(cherry picked from commit b98d2d3)

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
miss-islington added a commit that referenced this issue Dec 21, 2022
…-100142)

(cherry picked from commit b98d2d3)

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement
Projects
Status: No status
Development

No branches or pull requests

4 participants