On Nov 16, 5:12 pm, Steve Holden <[EMAIL PROTECTED]> wrote: >> The Python Reference Manual states that an object >> consists of identity, type, and value. "Identity" >> seems to be non-controversial. >> >> Let's take "type" as meaning the attributes an >> object inherits from it's class. "value" is then >> what is left: the object's local attributes and >> the intrinsic-value described above. >> >> This seems to be the most common view of "value", >> and similar to the one Fredrik Lundh takes in >> http://effbot.org/zone/python-objects.htm >> which was pointed to in an earlier response >> (he calls it "content") >> >> One could also take all attributes accessible >> through obj (its class' attributes as well as >> its local attributes) as "type" leaving only >> intrinsic-value as "value". >> This was the view I proposed. >> >> Or one could adopt what Terry Reedy called a >> 4-aspect view: an object is identity, class, >> value (or local-state or something) and >> intrinsic-value. >> >> I don't understand Python well enough to defend >> any of these descriptions (I now realize, despite >> my previous postings to the contrary. :-) >> >> But what I do defend is the concept of intrinsic >> value which I have not ever seen explicitly stated >> anywhere and which clarifies a lot of things for me. >> >> For example, you can define the value of None >> however you want, but it seems clear that it has >> (and needs) no intrinsic-value. Same with object(). > > In that case I am not sure why this happens: > >>>> a = object() >>>> b = object() >>>> a == b > False
Who said the equality operator compares values and that Python guarantees that it will always return True if the values of its arguments are the same? You yourself point out below that this is not true -- one can define "==" any way one wishes. If you can do so, can't the Python language developers who implement "==" also do so? In fact they did do so in this case, they compare id's. So the next question is, "why not define value equality (and implicitly values) to be whatever "==" says it is"? Well you could I suppose. The only hard constraints are that it be logically consistent, and not lead to erroneous conclusions about how Python works. Soft constraints are that in be easily understandable, and be intuitive. I don't know if using "==" would meet the two hard constraints, but it fails the two soft ones. The context of the definition of "value" in the Language Reference is where the basic properties of objects are being described. Why would one want to make the definition of objects, the core concept of Python, dependent on the behavior of the "==" operator? > Since those objects are of the same type, and since they have no > "intrinsic value", it would seem you'd expect them to be equal. But they > aren't, because (in the absence of an explicit equality test method) > equality is tested for by testing for identity. I would expect them to be equal, but apparently Python's designers thought otherwise. :-) The "==" operator is designed to return results that make the most sense (where sense is a complicated function in the brains of the Python developers.) In calculating that return value, Python need not return true for the "same" intrinsic values any more than than an object you define in Python has to. >> I now understand why the only way to describe the >> object int(2) is requires using str/repr whereas >> with objects without an intrinsic value, I can >> describe without needing str/repr. >> I can think of expressions as always returning >> objects, never "values". >> Etc... >> >> So, is this point of view any more acceptable? >> > Why not just accept that equality is determined by > the __eq__ method [2]? I do. But equality is not the same as "same-ness" [Oh god, here comes another round of philosophical discussion. :-)] > Python can have objects that > don't equal anything, even themselves, objects that > are equal to everything, and all definitions in between. > So "equality" doesn't necessarily mean that the values > are the same. Right! Which is exactly why equality is not the right concept for trying to think about, "what are the basic aspects of an object?" and "what is the value of an object?". > If objects have values that differ from the object itself, then aren't > those values themselves objects? If so, what are the values of those > objects? Yes, the intrinsic value of a list object contains (references to) other objects. But note that I did not claim to say *what* an instrinsic value was or what it's value was, only that: * it exists (in some but not all objects). * builtin[*3] methods and functions can access it and use it to decide what they will return. * that it is not accessible from Python language directly, only though the behavior of the those builtin methods/functions.[*4] * That however you define "value" in the P.L.R. sense) it must include intrinsic value (if any) So however P.L.R. "value" is defined, it must be recursive (i.e. the value of [1, [2, 3]] is different than [1, [2, 4]].) [*3] Again, I do not have a good term for this but mean code that is part of the implementation: for C-Python that would be C-API code that can directly access an object's implementation. [*4] That should probably be "may not be accessible..." since I could imagine an implementation like PyPy representing such "hidden state" using regular Python objects. > regards > Steve > >> [*1] I took note of Terry Reedy's point that >> a.__add__(b) is really int.__add__ (a, b) but >> since the two descriptions are isomorphic at >> the level I am discussing, it seemed clearer >> to leave class out of it. > > [2] This is a simplification, since the interpreter will fall back on > other methods in the absence of __eq__. -- http://mail.python.org/mailman/listinfo/python-list
