Michael Chermside: [Where PyObject_RichCompareBool is called, and the is shortcut might be a problem] Most of these operations -- including the container comparison -- are not well-defined if "is" does not imply equality. > I would intuitively expect that any contained objects > with customized comparison methods would have those methods > invoked. Yes, but you couldn't reliably predict the order they would be compared (I *choose* to start with the least significant! Oh yeah? Well I timsort with much galloping!), so inconsistent results are not guaranteed. The real problem is that you won't get the expected side effects. > I'm tending to think it's best to put the test for identity in > PyObject_RichCompareBool, but then how do we explain (in simple > terms) when user-defined comparison methods are invoked and when > they're not necessarily? Say that Python only promises to make the comparisons you explicitly ask for. Implicit comparisons (including cmp, sort, and comparisons between subobjects) may be optimized away. For example: a < b will compare a and b, but: [1, a] < [2, b] or even: [a] < [b] might not. -jJ
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