S
Steve Holden
That's OK. I don't assume you are arguing to be difficult, but to castI 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.
light on a dark area.
I now understand where your confusion arises, and I also have to acceptBut 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!$B!!(BThat'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.
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.
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