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.)
... 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).