-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
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
PyType_FromSpec*() overwrites the type's "__module__" #84880
Comments
The PyType_FromSpec() functions set the type's "__module__" attribute at the end: Lines 3154 to 3172 in 0509c45
There are only two possible cases, either it finds a module name in the spec name and sets "__module__" from that, or it outputs a deprecation warning. Both behaviours are annoying because they ignore anything that the type already has in its dict, e.g. a property entry from the "members" or "getset" structs. Since this code can't really be moved before the call to "PyType_Ready()" (which creates the type's dict and populates it), I think the best fix would be to first check if "__module__" is already in the dict and only otherwise take care of setting it. I noticed this when trying to make the "__module__" attribute of Cython's coroutine type work with type specs, which should actually return the instance specific module name, i.e. the module that defines the coroutine, not the module that defines the type. This would normally be solved with an entry in "members", but that is discarded by the code above. While this approach means that the type does not have its own "__module__" entry, I think the use cases of pickling and documentation support it, because they care about the module name of the instance, not of the type. I think working around this behaviour is somewhat easy by creating a new descriptor with PyDescr_NewMember() and re-adding it after calling PyType_FromSpec*(), so this is something that can just be fixed in Py3.9+. Relevant tickets: bpo-15146 for setting "__module__" and bpo-20204 for the deprecation warning. |
Thank you, Stefan! This should have a test as well. |
@encukou This change has been in use for about 3 years without testing. Is there still a need to write a test? |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: