Comparison of objects with recursive references is a cool feature but it leaves too many questions open and feels too much like a "do-what-i-mean" hack. Attached patch casts it into the obscure world of CVS history. On the positive side, the patch contributes a Py_EnterRecursiveCall()/Py_LeaveRecursiveCall() pair of functions to the C API, to use at any point where an infinite C-level recursion could occur. This is now used by: eval_frame() PyObject_Compare() PyObject_RichCompare() instance_call() and maybe it should be extended to cPickle.c, which has its own notion of maximum nesting as well. The diff also changes the tests to expect a RuntimeError when comparing nested structures.
Logged In: YES user_id=21627 I think the patch needs to be discussed on python-dev to get a chance to be accepted. It should also be accompanied with a more elaborate rationale, and a guideline on how applications that rely on the feature could detect the change, and how those applications need to be updated. For example, I find the change to the pickle tester unacceptable: you can't just drop the structural-equivalence test, since it is the primary purpose of this test to establish structural equivalence. So perhaps you should put a custom structural-equivalence algorithm into pickletester, and replace the assertEquals with that.
Logged In: YES user_id=4771 Ok. Before I reply to python-dev let me point out that I tried not to weaken any test. I guess you thought I just removed some tests, because I indeed usually replaced a group of self.assertXxx() lines with a smaller number of assertions, but as far as I can tell they all test the structure as much as the original assertions, and sometimes even more.
Logged In: YES user_id=4771 Another version of the patch. This one is quite faster -- I'm measuring the performance of: a = [5] * 1000 b = [a] * 1000 b == b for which test is appears now to have no measurable penalty. The drawback of this patch is a few extra obscure macros in ceval.h. Read the new comment in ceval.c for the idea.
