RetroSearch Browse

Tue May 18 13:24:56 EDT 2004 · http://mail.python.org/pipermail/python-dev/2004-May/044892.html

Armin Rigo:

	say x has a method __cmp__() that always 
	returns -1.

	>>> x == x             #   x.__cmp__() is called
	False
	>>> x < x              #   x.__cmp__() is called
	True
	>>> cmp(x,x)           #   x.__cmp__() is NOT called
	0
	>>> [x] == [x]         #   x.__cmp__() is NOT called
	True

Note that the last (and only the last) is a change from 2.3
In 2.3, the (identity does not imply equality) trait rolls up 
to containers.

>>> l=[x]
>>> l == l
False

	The only way to explain the semantic is that the expression 
	'x == x' always call the special methods, but built-in functions 
	are allowed to assume that any object compares equal to itself.  

Note that "allowed" is as strong as you can get; is implies ==, but 
does not (currently) imply <= or preclude <.

	Should any of this be documented?

I think so; it is a problem only for pathological cases, but who would 
bother to look up rich comparison in the first place unless they were 
considering at least borderline strangeness.

	An alternative behavior would have been to leave 
	PyObject_RichCompareBool() alone and only insert the short-cut 
	on specific object types' comparison methods

I think it is reasonable for the default to be that identity implies
equality.  Either an explicitly defined __cmp__ should always be
called, or the notes should say that containers can treat identity
as good enough.  

	This is sane as long as no code considers 'nan' as a singleton, 
	or tries to reuse 'nan' objects for different 'nan' values.

Note that float('nan') raises on ValueError on at least the default 
windows 2.3 build; if a NaN is hard to get, I would expect it to be 
reused.

-jJ

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2004-May/044892.html below:

[Python-Dev] cmp(x,x)