
Two things spoken by Guido:
But millions of tuples are not uncommon. They're probably the only thing to worry about here.
Unfortunately, the visit API doesn't make it easy to watch this[*]; a tuple calls visit() on its items but learns nothing except whether it failed. (I've never seen a visit() implementation that could fail, so I'm not sure even why the return code exists.)
* "this" is the number of tracked objects visited during a GC scan, as described by MvL
If visit() does something sensible (like traversing a directed, potentially cyclic graph), then the only way it could fail is to not return. No doubt there is a clear record of who calls this function.
Why not we change the semantics of visit() in this case to provide the required information? Make visit() return a non-negative integer for "number of tracked objects seen". If someone can find a good reason for error codes, then there is the negative half of the integer number line. (/me is going out on a limb and hypothesizing that visit() is in C for all relevant cases.)

[Ian Kjos]
... Why not we change the semantics of visit() in this case to provide the required information?
There is no function named "visit", and the semantics of tp_traverse are etched in stone because extension modules we don't control already implement its long-advertised interface. No offense intended, but if you want to help with this you should really learn what the Python implementation does first; random ideas (which may or may not apply in some other implementation) are a distraction on Python-Dev (this list pretends <0.9 wink> to be more focused than c.l.py).
participants (2)
-
Ian Kjos
-
Tim Peters