[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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4