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.