-
Notifications
You must be signed in to change notification settings - Fork 64
Better handling of hidden builtins #278
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
base: main
Are you sure you want to change the base?
Conversation
Added a generalized algorithm to handle builtins exposed via the `types` module, but reporting `builtins` at introspection.
| return QualifiedName((Identifier("None"),)) | ||
|
|
||
| hidden_builtin = self._hidden_builtins.get(typename) | ||
| if hidden_builtin is not None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you want to add a few inline comments to make the logic easier to read (e.g., what you wrote in the PR description)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, will do.
|
Test cases for this also need to be added. |
Added a generalized algorithm to handle builtins exposed via the
typesmodule, but reportingbuiltinsat introspection.Why
Importing types, via pybind11 such as py::module::import("types").attr("MappingProxyType") currently yields an unresolved name "mappingproxy" in the generated .pyi stubs.
The reason for this is that the
MappingProxyType.__qualname__at runtime is "mappingproxy" and__module__is "builtins". However, the actual builtins module does not expose this as an importable attribute.There are a number of other "hidden" builtins that follow this pattern. They all seem to come from the types module. I also left room for overriding this behavior, as was done before for "function" and "builtin_function_or_method".