RetroSearch Browse

Mon Jul 7 23:11:03 CEST 2014 · https://mail.python.org/pipermail/python-dev/2014-July/135342.html

07.07.2014 18:11, Andreas Maier wrote:

> Am 07.07.2014 17:58, schrieb Xavier Morel:
>>
>> On 2014-07-07, at 13:22 , Andreas Maier <andreas.r.maier at gmx.de> 
>> wrote:
>>
>>> While discussing Python issue #12067 
>>> (http://bugs.python.org/issue12067#msg222442), I learned that Python 
>>> 3.4 implements '==' and '!=' on the object type such that if no 
>>> special equality test operations are implemented in derived classes, 
>>> there is a default implementation that tests for identity (as opposed 
>>> to equality of the values).
[...]
>>> IMHO, that default implementation contradicts the definition that 
>>> '==' and '!=' test for equality of the values of an object.
[...]
>>> To me, a sensible default implementation for == on object would be 
>>> (in Python):
>>>
>>>   if v is w:
>>>     return True;
>>>   elif type(v) != type(w):
>>>     return False
>>>   else:
>>>     raise ValueError("Equality cannot be determined in default 
>>> implementation")
>>
>> Why would comparing two objects of different types return False
>
> Because I think (but I'm not sure) that the type should play a role
> for comparison of values. But maybe that does not embrace duck typing
> sufficiently, and the type should be ignored by default for comparing
> object values.
>
>> but comparing two objects of the same type raise an error?
>
> That I'm sure of: Because the default implementation (after having
> exhausted all possibilities of calling __eq__ and friends) has no way
> to find out whether the values(!!) of the objects are equal.

IMHO, in Python context, "value" is a very vague term.  Quite often we 
can read it as the very basic (but not the only one) notion of "what 
makes objects being equal or not" -- and then saying that "objects are 
compared by value" is a tautology.

In other words, what object's "value" is -- is dependent on its nature: 
e.g. the value of a list is what are the values of its consecutive 
(indexed) items; the value of a set is based on values of all its 
elements without notion of order or repetition; the value of a number is 
a set of its abstract mathematical properties that determine what makes 
objects being equal, greater, lesser, how particular arithmetic 
operations work etc...

I think, there is no universal notion of "the value of a Python 
object".  The notion of identity seems to be most generic (every object 
has it, event if it does not have any other property) -- and that's why 
by default it is used to define the most basic feature of object's 
*value*, i.e. "what makes objects being equal or not" (== and !=).  
Another possibility would be to raise TypeError but, as Ethan Furman 
wrote, it would be impractical (e.g. key-type-heterogenic dicts or sets 
would be practically impossible to work with).  On the other hand, the 
notion of sorting order (< > <= >=) is a much more specialized object 
property.

Cheers.
*j

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

Showing content from https://mail.python.org/pipermail/python-dev/2014-July/135342.html below:

[Python-Dev] == on object tests identity in 3.x