Repository navigation
Allow _PyType_Lookup() to raise exceptions #75646
Description
Activity
Follow-up to bpo-31336:
The fact that _PyType_Lookup() does not propagate exceptions leaves some space for ambiguity. If, in a chain of MRO lookups, one would fail and a later one would succeed, is it correct to keep trying? What if the first failure actually failed to see an otherwise existing attribute in that class? We simply can't know because the lookup failed for *some* reason.I think, the only way to really avoid that ambiguity would be to allow _PyType_Lookup() to raise exceptions, and to make it fail on the first error.
I'm working on a PR for this, but after changing all usages and fixing up some error handling here and there, it results in an interpreter crash for me. I'll try to debug it during the next days.
Test suite passes now. The crash was due to an uninitialised error flag in one case, which lead the C compiler to do incorrect optimisations on undefined behaviour.
Question: Do you think it's ok to change the signature of _PyType_Lookup() in this way by adding an error flag, or should I add a new function instead?
There is no performance difference to PR 3279 since gcc should optimise this flag properly away in most cases, so it's not a question about performance but about backwards compatibility. It's an internal, private function, which suggests that it should be ok, but it's not my decision. Cython calls it in a couple of cases, which I will obviously adapt in the next release, if the signature change is accepted.
Should the "no MRO after readying" error case be kept? It's the only non-exception error case, setting the error flag to 1. It seems ok to ignore this case, so it's not really an error, somehow. I would change it to return 0 (instead of 1), and thus change the error flag to simply "-1 on error (with exception set), 0 on success". Opinions?
Any comments on this?
I'm positive to this change in general, but this is too complex and delicate code. In needs careful reviewing.
As Mark said on the PR:
I would prefer a new function, rather than modifying the signature of _PyType_Lookup.
Also, I think it is the conventional to return error codes directly and objects via the pointer, not the other way around. Soint _PyType_Lookup(type, name, *result)not PyObject*_PyType_Lookup(type, name, *error)That's still the case. Additionally, for the return value we standardized on -1 for exception, 0 for not found, 1 for found. On -1 or 0,
*resultgets set to NULL.But also, it looks like CPython is doing just fine with the exception-swallowing function.
I'll close this issue; I don't think it's actionable as written without more discussion.If this function is useful outside CPython, that should be a new public function. But, it's not clear why it's needed. It does look like a good thing to add, but it needs a clear case for it. We do need to understand why it's needed, and document it properly.
To push this forward, please comment on Discourse (or in capi-workgroup/decisions#83 (comment) -- we can reopen that).cc @da-woods
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: