[Python-Dev] PyObject_RichCompareBool identity shortcut (original) (raw)
Guido van Rossum guido at python.org
Fri Apr 29 01:13:58 CEST 2011
- Previous message: [Python-Dev] PyObject_RichCompareBool identity shortcut
- Next message: [Python-Dev] PyObject_RichCompareBool identity shortcut
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, Apr 28, 2011 at 4:04 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
On Fri, Apr 29, 2011 at 8:55 AM, Guido van Rossum <guido at python.org> wrote:
Sorry, we'll have to make an exception for those of course. This will somewhat complicate the interpretation of well-behaved, because those are not well-behaved as far as containers go (both dict key lookup and list membership are affected) but it is not a bug -- however it is a bug to put these in containers and then use container comparisons on the container. That's a point in favour of the status quo, though - with the burden of enforcing reflexivity placed on the containers, types are free to make use of rich comparisons to return more than just simple True/False results.
Possibly. Though for types that do return True/False, NaN's behavior can still be infuriating.
I hadn't really thought about it that way before this discussion - it is the identity checking behaviour of the builtin containers that lets us sensibly handle cases like sets of NumPy arrays.
But do they? For non-empty arrays, eq will always return something that is considered true, so any hash collisions will cause false positives. And look at this simple example:
class C(list): ... def eq(self, other): ... if isinstance(other, C): ... return [x == y for x, y in zip(self, other)] ... a = C([1,2,3]) b = C([2,1,3]) a == b [False, False, True] x = [a, a] b in x True
-- --Guido van Rossum (python.org/~guido)
- Previous message: [Python-Dev] PyObject_RichCompareBool identity shortcut
- Next message: [Python-Dev] PyObject_RichCompareBool identity shortcut
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]