[Python-Dev] == on object tests identity in 3.x
andreas.r.maier at gmx.de
Tue Jul 8 01:37:09 CEST 2014
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 <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
>>>> raise ValueError("Equality cannot be determined in default
>>> 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
I'll try to summarize in a separate posting.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev