Guido van Rossum wrote:
> 2008/8/21 Nick Coghlan <[EMAIL PROTECTED]>:
>> Levi wrote:
>>> Now, I understand that set doesn't return NotImplemented to avoid having
>>> it's __cmp__ method called, but what I don't get is why it has a __cmp__
>>> method at all. I thought the entire point of set and co. using the rich
>>> comparison operators is that Sets only define a partial ordering and so
>>> shouldn't define __cmp__, which implies a total ordering. So why define
>>> a __cmp__ method that only raises an error at the expense of breaking
>>> the rich comparison operators?
>> set() and frozenset() do this to prevent falling back to the default
>> ordering employed in Python 2.x:
>>
>>>>> obj1 = type('T1', (), {})
>>>>> obj2 = type('T2', (), {})
>>>>> obj1 < obj2
>> True
>>>>> obj1 > obj2
>> False
>>
>> It should be possible to make them play more nicely with others in 3.x
>> where that undesirable fallback behaviour is gone though.
>
> I thought in 3.0 they already behave cooperatively? set_richcompare()
> returns NotImplemented (where in 2.x it raises TypeError.)
Other than look to see if __cmp__ was still in dir(set) (which it is), I
didn't actually check if this had been corrected already... perhaps Levi
should retry his experiment with the latest 3.0 beta instead of 2.6?
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
