Messages (6) msg302156 - (view) Author: Stefan Behnel (scoder) * Date: 2017-09-14 08:07

Follow-up to issue 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.

msg302211 - (view) Author: Stefan Behnel (scoder) * Date: 2017-09-14 21:22

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.

msg302336 - (view) Author: Stefan Behnel (scoder) * Date: 2017-09-16 11:59

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.

msg302413 - (view) Author: Stefan Behnel (scoder) * Date: 2017-09-18 07:19

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?

msg303009 - (view) Author: Stefan Behnel (scoder) * Date: 2017-09-26 05:58

Any comments on this?

msg303456 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * Date: 2017-10-01 08:44

I'm positive to this change in general, but this is too complex and delicate code. In needs careful reviewing.

History Date User Action Args 2022-04-11 14:58:52adminsetgithub: 75646 2017-10-01 08:44:44serhiy.storchakasetpull_requests: - pull_request3632 2017-10-01 08:44:38serhiy.storchakasetmessages: + msg303456 2017-09-28 17:07:33pitrousetnosy: - pitrou
2017-09-28 16:32:33scodersetnosy: + vstinner
2017-09-26 05:58:57scodersetmessages: + msg303009 2017-09-18 07:28:41scodersetpull_requests: + pull_request3632 2017-09-18 07:19:37scodersetmessages: + msg302413 2017-09-16 11:59:19scodersetmessages: + msg302336 2017-09-16 11:55:02scodersetkeywords: + patch
stage: patch review
pull_requests: + pull_request3607 2017-09-14 21:22:33scodersetnosy: + pitrou, serhiy.storchaka
messages: + msg302211
2017-09-14 08:07:19scodercreate