Am 2014-07-07 23:11, schrieb Jan         Kaliszewski:
             
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              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. 
             
      On the universal notion of a value in Python: In both 2.x and 3.x,       it reads (in 3.1. Objects, values and types):
      - "Every object has an identity, a type and a value."
      - "An object’s identity never changes once it has been       created; .... The value of some objects can change.       Objects whose value can change are said to be mutable;       objects whose value is unchangeable once they are created are       called immutable."
      
      These are clear indications that there is an intention to have       separate concepts of identity and value in Python. If an instance       of type object can exist but does not have a universal notion of       value, it should not allow operations that need a value.
      
      I do not really buy into the arguments that try to show how       identity and value are somehow the same. They are not, not even in       Python.
      
      The argument I can absolutely buy into is that the implementation       cannot be changed within a major release. So the real question is       how we document it.
      
      I'll try to summarize in a separate posting.
      
      Andy
      
      
         
   ">

(original) (raw)


Am 2014-07-07 23:11, schrieb Jan Kaliszewski:
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 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.

On the universal notion of a value in Python: In both 2.x and 3.x, it reads (in 3.1\. Objects, values and types):
\- "Every object has an identity, a type and a value."
\- "An object’s identity never changes once it has been created; .... The value of some objects can change. Objects whose value can change are said to be mutable; objects whose value is unchangeable once they are created are called immutable."

These are clear indications that there is an intention to have separate concepts of identity and value in Python. If an instance of type object can exist but does not have a universal notion of value, it should not allow operations that need a value.

I do not really buy into the arguments that try to show how identity and value are somehow the same. They are not, not even in Python.

The argument I can absolutely buy into is that the implementation cannot be changed within a major release. So the real question is how we document it.

I'll try to summarize in a separate posting.

Andy