Irit Katriel <iritkatr...@gmail.com> added the comment:
> > the result is C -> A -> B -> C > Did you mean C -> A -> B? No, I meant C -> A -> B -> C -> A .... the cycle remains unchanged. > By the way, if you applied to this example your reasoning that > PyErr_SetObject shouldn't try to fix user bugs, should this example instead > be C -> A -> B -> C -> ... (leaving the cycle as is but just not hanging)? Yes, exactly, see above. > Is it not being changed then because the reasoning doesn't apply, or because > we're restricted in what we can do by backwards compatibility? The reason for leaving the cycle unchanged is not backwards compatibility, it's that this function cannot break the cycle in a meaningful way (this is why it's hard to agree on how it should do that). It can't be that A happened in the context of B at the same time that B happened in the context of A. So a cycle means there was a bug somewhere, and the exception's history is corrupt, so changing it will only make it more corrupt and harder to debug. Note that PyErr_SetObject avoids creating cycles, so the cycle was not created by someone catching an exception e and doing "raise e". It was caused by some other code tampering with the __context__ in an incorrect way. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue25782> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
