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

[Steve Holden]

rurpy at yahoo.com wrote:
> On Nov 18, 10:22 am, Steve Holden <st... at holdenweb.com> wrote
> in thread "Python-URL! weekly Python news and links (Nov 17)":
>> rurpy at yahoo.com wrote:
>> [...]
>>> One of the reasons I would like to formulate a good
>>> model of an object's value and type is so that I could
>>> try to offer something better.  Responses like yours
>>> are significantly demotivating.
>> And yet you argue when people try to explain to you that objects don't
>> *have* values, objects *are* values. Objects have attributes, which are
>> references to other values. One of an object's attributes is its type.
> 
> I am sorry for arguing with you.  I hear you
> and others saying that the value (in the english
> language sense of value) of an object *is* the
> object.
> 
That's OK. I don't assume you are arguing to be difficult, but to cast
light on a dark area.

> But before I address that, I am a little confused
> by what you wrote above.  Quoting the PLR again,
> "Every object has an identity, a type and a value."
> I presumed "value" to include attributes.  Are you
> saying the correct statement in the PLR should have
> been, "Every object has an identity, attributes, and
> a value"?
> 
> The text below refers to identity, type and value
> per the PLR, but you can substitute "attributes"
> for type without affecting the logic.
> 
> Here is why I am having trouble accepting the
> explanations you and others have kindly offered
> me.  If values are objects then the words "object"
> and "value" are synonymous, yes?  Fine, I can see
> that could be a desirable thing.  Value is more
> natural than object for people coming to Python,
> for example.
> 
> But if you use the word value synonymously with
> object, then the PLR statement that "an object
> has identity, type, and value" is the same as "an
> object has identity, type, and itself".  We know
> the object is itself!　That's tautological.  So
> what is the point of using the term value in the
> definition of "object"?  You can just say "an object
> has identity and type, and we will also use the word
> value as a synonmym for object."
> 
> Other than cosmetics, the word "value" serves no
> purpose and we can replace it with "object" wherever
> we use it.  E.g. "the result of evaluating an
> expression is a value.", "the result of evaluating
> an expression is an object".  If value is the same
> as object, then Python objects have only identity
> and type.
> 
> But you know that's not true.  The types of int(2)
> and int(3) are the same.  Is the difference in
> behavior of the two objects due to their different
> identities?!  Python knows the object at 0x260FF44
> is a "2" object, and the object at 0x260FD60 is a
> "3" solely by virtue of their addresses?
> 
> Of course not.
> I hope you see why I find the "value is object"
> to be an unacceptable explanation of Python
> objects.
> 
I now understand where your confusion arises, and I also have to accept
that integer types have a value that isn't formally available as an
attribute.

However, I don't personally see the need to go beyond the Python object
"2", since operations involving that value are not programmed in Python
but in the underlying implementation language.

>> You seem to be hunting for the ineffable
>> "primitive value" that has no other attributes.
>> Such a thing doesn't exist.
> 
> Sorry to argue again, but I explained (in a
> previous post) why I believe such a thing does
> exist.  Specifically, it is necessary to explain
> the difference between the objects int(2) and
> int(3).  Perhaps if you tell me exactly what
> fault you find with that previous explanation
> (in light of my problem with "values are objects"
> above), I could reevaluate my understanding.

I suppose I was thinking more of the compound values than the primitive
immutable type instances. I take your point that int(3) and int(2) do
indeed differ by virtue of having different values for some "hidden
attribute" that isn't available to the Python programmer.

Since the differences aren't directly addressable in Python, however, I
prefer to ignore them :)

regards
 Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/