I wrote: > Performance is certainly a legitimate concern. Armin replied: > Ok, then the current situation looks like the best one. I > suggest we just > drop a note in the documentation saying that if there are > objects for which > x.__eq__(x) isn't necessarily true, you shouldn't expect them > to be handled in > a fully consistent way. [...] > There is an extra costly indirection until the execution > reaches that point. Armin: Performance is a *legitimate* concern, but not an *overwhelming* one. If we are in danger of having to walk over the entirety of a (possibly large) recusive structure (eg: tuple of tuples) to do a comparison, then that's dangerously slow, and it's worth mucking with the definition of equality to avoid it. But a single indirection is "costly" only to someone capable of reaching your level of close-to-the-machine performance understanding. I say, go with your original plan -- the current behavior is a mess. -- Michael Chermside
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