Message409176
The recursion protection in `saferepr` applies when two conditions are met:
- the structure is subclassed from list, tuple or dict
- __repr__ is not overriden
In this case neither condition is met.
However, the recursion is caused by the `__repr__` so when it's removed, recursion doesn't happen (but not due to recursion protection).
Btw also note that recursive path must be continuous for recursion detection to apply, e.g. if it's list[cust_obj[list[cust_obj...]]], detection also won't work.
I don't think we can fix this in code in a straightforward way, because we want to avoid recursively calling saferepr in case __repr__ does not recurse.
In other words, if we knew __repr__ DOES recurse, we could call saferepr recursively and apply recursion detection without any problems, but __repr__ might intentionally say something like "<Mylist: 1423434 items>", and then recursively calling saferepr would be undesirable.
So unfortunately we lose the recursion detection because of that.
One possible option would be to add an optional param like *force_recursion*, to recurse with detection even on overridden *__repr__*. I'm not sure it's worth it. But that's something users can consider: subclass PrettyPrinter and override saferepr() and either remove the checks for __repr__ override or add a param to do just that.
Current docs really make it sound like any recursion that shows up in repr() will be protected; it's really much more limited than that. Adding PR to clarify the limitations. |
|
Date |
User |
Action |
Args |
2021-12-25 22:49:13 | andrei.avk | set | recipients:
+ andrei.avk, iritkatriel, danbst |
2021-12-25 22:49:13 | andrei.avk | set | messageid: <1640472553.42.0.31208084636.issue42259@roundup.psfhosted.org> |
2021-12-25 22:49:13 | andrei.avk | link | issue42259 messages |
2021-12-25 22:49:13 | andrei.avk | create | |
|