[Python-Dev] very slow compare of recursive objects

[Tim Peters]

[Martin v. L=F6wis]
> It doesn't: You can't create a tuple that contains itself, except o=
n
> the C level (which I would declare a bug in the C code that does so=
).
> So any cycle involving a tuple must involve a non-tuple object as
> well.

[Jeff Epler]
> But a tuple subclass can.  Does the code use PyTuple_Check or
> PyTuple_CheckExact?

It did use PyTuple_Check, and still does in 2.2.  Likewise PyString_C=
heck.
I already changed 2.3 to use the XYZ_CheckExact() spellings instead.
Leaving repair of 2.2 to someone who cares more than I do <wink>.

WRT speed, this isn't going to get faster unless something akin to my
original patch (posted here) is used to keep on using the inprogress =
dict
even when compare_nesting falls below NESTING_LIMIT again.  The patch=
 I
posted here wasn't safe, because it can't know that the saved-away ad=
dresses
still refer to the same objects.  That could be repaired by changing =
the
inprogress dict to map "tokens" to comparand pairs (instead of to
themselves).  The references to the comparand objects in the dict val=
ues
would ensure the objects stayed alive until the dict entry was cleare=
d.  I'm
out of time for this, so if someone cares enough, that's what to do.