Issue 29855: The traceback compounding of RecursionError fails to work with get (original) (raw)

Issue29855

Created on 2017-03-19 23:37 by bup, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (3)
msg289867 - (view) Author: Dan Snider (bup) * Date: 2017-03-19 23:37
class Property: def __init__(self, getter): self.getter = getter def __get__(self, instance, cls): return self.getter(cls if instance is None else instance) class MyClass: @Property def something(cls): return cls.something Calling MyClass.something will show all 990+ RecursionError message.
msg289871 - (view) Author: Jim Fasarakis-Hilliard (Jim Fasarakis-Hilliard) * Date: 2017-03-20 03:58
I'm pretty sure this is by design; the change introduced in [1] tried to keep things simple by only trimming the output when the lines were identical. More complicated scenarios are trickier to implement. It should be interesting to see if the core-devs believe a change like this is warranted, though. [1]: https://bugs.python.org/issue26823
msg289875 - (view) Author: Alyssa Coghlan (ncoghlan) * (Python committer) Date: 2017-03-20 06:41
Indeed, the traceback abbreviation doesn't try to detect recursive loops, only exactly duplicated lines. The problem is that the more state management we do in the traceback printing, the higher the chance there is of getting an error while attempt to display the previous errors. Keeping the immediately preceding entry and doing an exact comparison is straightforward, but pattern matching on up-to-N entries is something we'll leave to external traceback pretty printers.
History
Date User Action Args
2022-04-11 14:58:44 admin set github: 74041
2017-03-20 06:41:40 ncoghlan set status: open -> closedresolution: not a bugmessages: + stage: resolved
2017-03-20 04:02:31 xiang.zhang set nosy: + ncoghlan, abarry
2017-03-20 03:58:58 Jim Fasarakis-Hilliard set versions: + Python 3.7nosy: + Jim Fasarakis-Hilliardmessages: + components: + Interpreter Core
2017-03-19 23:37:32 bup create