Official definition of call-by-value (Re: Finding the instance reference...)

[rurpy at yahoo.com]

On Nov 16, 5:12 pm, Steve Holden <st... at holdenweb.com> 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__.