Terry Reedy wrote:
>> In the case of the comparison methods, they're being retrieved from type
>> rather than object. This difference is made clear when you attempt to
>> invoke the retrieved method:
>>
>>>>> object.__cmp__(1, 2)
>> Traceback (most recent call last):
>> File "<stdin>", line 1, in <module>
>> TypeError: expected 1 arguments, got 2
>>>>> object.__cmp__(2)
>> Traceback (most recent call last):
>> File "<stdin>", line 1, in <module>
>> TypeError: type.__cmp__(x,y) requires y to be a 'type', not a 'int'
>>>>> object.__cmp__(object)
>> 0
>
> This surprises me, partly because the situation seems to be different in
> 3.0.
That's because the default comparison of object() instances also changes
in Py3k: equality and inequality checks will succeed (using identity
based comparison), but ordering checks will fail with a TypeError.
The rich comparisons on type() in 2.6 are actually there in order to
issue a Py3k warning when -3 is defined and an ordering comparison is
invoked on a type, but it appears no such warning is currently present
for default object comparison.
That lack of Py3k warnings is arguably a bug in 2.6, but we would want
to think carefully about the backwards compatibility implications of
defining rich comparisons on object before adding such warnings. As
we've seen, even adding rich comparisons to type was enough to break
some user code (admittedly it was code that made some unwarranted
assumptions and hence was already potentially broken in the face of
metaclasses other than type, but the change did in fact break that code
for cases where it used to work).
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
