<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-forward-container">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Am 2014-07-07 23:11, schrieb Jan
Kaliszewski:<br>
</div>
<blockquote
cite="mid:8564322772978800ae89623d1426b469@chopin.edu.pl"
type="cite">07.07.2014 18:11, Andreas Maier wrote: <br>
<blockquote type="cite">Am 07.07.2014 17:58, schrieb Xavier
Morel:<br>
<blockquote type="cite">On 2014-07-07, at 13:22 , Andreas
Maier <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:andreas.r.maier@gmx.de"><andreas.r.maier@gmx.de></a>
wrote: <br>
<br>
<blockquote type="cite">While discussing Python issue #12067
(<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://bugs.python.org/issue12067#msg222442">http://bugs.python.org/issue12067#msg222442</a>),
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). <br>
</blockquote>
</blockquote>
</blockquote>
[...] <br>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">IMHO, that default implementation
contradicts the definition that '==' and '!=' test for
equality of the values of an object. <br>
</blockquote>
</blockquote>
</blockquote>
[...] <br>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">To me, a sensible default
implementation for == on object would be (in Python): <br>
<br>
if v is w: <br>
return True; <br>
elif type(v) != type(w): <br>
return False <br>
else: <br>
raise ValueError("Equality cannot be determined in
default implementation") <br>
</blockquote>
<br>
Why would comparing two objects of different types return
False <br>
</blockquote>
<br>
Because I think (but I'm not sure) that the type should play a
role <br>
for comparison of values. But maybe that does not embrace duck
typing <br>
sufficiently, and the type should be ignored by default for
comparing <br>
object values. <br>
<br>
<blockquote type="cite">but comparing two objects of the same
type raise an error? <br>
</blockquote>
<br>
That I'm sure of: Because the default implementation (after
having <br>
exhausted all possibilities of calling __eq__ and friends) has
no way <br>
to find out whether the values(!!) of the objects are equal. <br>
</blockquote>
<br>
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. <br>
<br>
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... <br>
<br>
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. <br>
</blockquote>
<br>
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):<br>
- "Every object has an identity, a type and a value."<br>
- "An object’s <em>identity</em> never changes once it has been
created; .... The <em>value</em> of some objects can change.
Objects whose value can change are said to be <em>mutable</em>;
objects whose value is unchangeable once they are created are
called <em>immutable</em>."<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I'll try to summarize in a separate posting.<br>
<br>
Andy<br>
<br>
<br>
</div>
<br>
</body>
</html>