Finding the instance reference of an object

D

Derek Martin

Well, sure, if you care *that much* about potentially trivial aspects. I
have a ten dollar note with a spec of dirt on one corner, and a ten
dollar note with a slightly larger spec of dirt on a different corner.
I'd agree with you that they are not "the same" in every aspect, but
they're the same in every way I care about.

It's trivial to show that this is not necessarily the case -- you just
haven't thought of all the ways in which a difference might matter to
you..

Suppose that one of the 10-dollar bills had a serial number which was
never printed by the government (i.e. it is counterfiet). Are they
still the same in every way that you care about?

What is the value of these two objects? Is it the same?

The answer, in both cases, is, "it depends." The value of both is
context-specific, just as I argue is the value of a python object.
First let's briefly examine the value of the counterfiet:

The "intrinsic" value (or rather, the value generally accepted by the
authorities) of the counterfeit is zero. However, if you have one in
your hand, and you pass it to a merchant who is not able to detect
that it is a counterfeit, then, isn't its value $10 in that context?
If you walk away from the merchant with $10 worth of goods (and/or
change in non-counterfeit currency), then I would say it would have to
be, *in that context*.

Now suppose that the merchant is actually a U.S. Secret Service agent
investigating counterfeit money. He notices the bill and arrests you.
What is the value of the bill now? I doubt you could really measure
it, except perhaps in terms of the amount of money it would cost you
to defend yourself in court (if your case went to court), the amount
of hastle to deal with the authorities, etc. Suffice it to say that
the value is rather negative, possibly with a very high magnitude,
depending on what happens next.

What about the genuine $10 bill?

If you take it to your local mall, or your local gas station, or your
corner grocer, it's clearly worth $10... or is it? Prices of gasoline
vary from station to station, city to city, state to state, even if
the gas is sold by the same company. A can of peas might be $0.89 at
a market in New Hampshire, or the same can of peas might be $1.59 at a
market in down town Manhattan. And if you take your $10 bill to pay
for your favorite cup of coffee at Starbucks in your city, it might
cost you $4 with change back of $6... But if you bring that same $10
bill to a Starbucks in a small city in Germany, good luck getting any
coffee...

Just as in the real world, the value of a Python object depends on the
context in which it is evaluated.
What are the aspects of the object that I can look at?

id(obj) will give me the identity but I know that will be different and
so its irrelevant.

Philosophically, no, not irrelevant. You haven't explicitly defined "the
same" in enough detail to make that call. Perhaps because the objects are
in different locations (different IDs) is enough to make them different,
even if everything else about them is identical.

For example, consider the two electrons around a helium nucleus. They
have the same mass, the same speed, the same spin, the same electric
charge, the same magnetic moment, they even have the same location in
space (technically, the same wave function). They are identical in every
possible way. Are they the same electron, or two different electrons?
What does the question even mean?

My point is that as a philosophical position, identity may or may not
count as "sameness". It depends on the circumstances.


What else can we look at? We can go through each
attribute of the objects looking for an attribute that one has and the
other doesn't, or for attributes of the same name that are different.

We look at .__class__, .__delattr__, .... and so on and they are all the
same until we come to .foo and note that a.foo and b.foo are different.
One is an int(1) object, the other is an int(2) object. So we can say
that a and b are different.

Philosophically, sure, but practically, perhaps not. The foo attribute
may be entirely irrelevant to your purposes, the equivalent of a random
speck of dirt or a slight tear on a ten dollar note.

Luckily, Python doesn't try to guess whether differences are significant
or not. You can override the __eq__ method on classes and choose for
yourself what properties of a class are differences that make a
difference and which are mere markers of no particular concern.

Lets do the same with these two objects:

a = int(2)
b = int(3)

When we do that, we find no difference! Every attribute is the same in
both a and b! WTF!?

That's because you haven't asked the objects themselves if they are the
same. Not every aspect of objects are implemented as attributes.


But we know when we call a's .__add__ method [*1]
with the argument 1, we get a different result than when we call b's
__add__ method with the argument 1.

Somehow, built into the internal representation of the int(2) object, is
some representation of the number 2 and the int(2) object's __add__()
method accesses this representation in order to decide that it has to
create an int(3) object to return, rather than creating an int(47)
object to return.
But why don't we see this "2" when we examine the object?

Of course you do. Just look at the object and you will see it is a 2.


Why isn't
there a .value attribute or something holding 2?

Why should there be a value attribute? Python attributes are just a
particular interface for accessing data. It's not the only possible
interface.

We look at everything we can

You forgot to look at the object as a whole. Consider a pair of trousers.
You're rifling through the pockets of one looking for a coin or a wallet
or some other object to distinguish it from another pair of trousers,
without noticing that one is made of blue cotton and the other is green
spandex.


but we can see no difference between the two objects, nothing
that tells us that one is a 2, and the other a 3.

The objects themselves tell us that they are 2 or 3. They don't need an
extra attribute, and in fact the implementation of int objects don't
allow for extra attributes because they have no __dict__ to store them in.

So clearly the 2-ness of int(2) is built into the object and is not
visible *except* in it behavior. The int(2)'s __add__ method knows how
to access it, so do __repr() and __str__() and other methods. But short
of using those methods, there is no way for me (the programmer using
Python) to access it. The 2-ness is some sort of intrinsic property of
the int(2) object. I will call it "intrinsic value".

I don't think this is a valuable distinction to make. What's the
intrinsic value of a dict?


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.

Let's not.

The type of an object is a label that tells Python where to look in order
to interpret the object. It is certainly *not* the attributes on the
object:
<type 'int'>


"value" is then what is left: the object's local attributes and
the intrinsic-value described above.

What do you mean by "local attributes"?

Do you mean instance attributes? That's well defined: an attribute is an
instance attribute if it is in obj.__dict__. It is a class attribute if
it is in obj.__class__.__dict__.

(Slots make this a little more complicated in practice, but we can ignore
them for now.)

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 think we gain anything from distinguishing value and intrinsic
value, except confusion.


How do you deal with compound objects. What's the value of [1, 2, 3] if
it isn't "the list consisting of ints 1, 2 and 3"?

And recursive objects?

class Parrot:
def __init__(self):
self.me = self

p = Parrot()

a = []
a.append(a)



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.

Think about lists. The "intrinsic" value of a list is the items in the
list itself, if it is anything, but you have an interface for looking at
them individually:

alist

Here's another problem with your idea of "intrinsic value". Consider a
list. The list object in CPython is an array of cells, containing data.
Some of those cells are in use, some of them are free, but regardless of
whether they are free or in use they still have data in them. (The data
may be obsolete in the case of the free cells. The list object also
includes a cell which records the number of cells in the array, and
another cell recording private information of use to the Python garbage
collector. These cells are not necessarily the same size.

Are they part of the "intrinsic value"? You can't access them via
attributes.

What if we use another implementation of list, say, a linked list? What
if we use PyPy, an implementation of Python in Python, and (for the sake
of the argument) lists are implemented as follows:

class list(object): # untested
def __init__(self, values):
for i, x in enumerate(values):
setattr(self, i, x)

(This would make a lousy implementation. Don't try it!) Does that mean
that the value of [1, 2, 3] depends on the implementation of Python you
create it under?


For example, you can define the value of None however you want, but it
seems clear that it has (and needs) no intrinsic-value.

To me, that seems just as silly as arguing that zero is not a number, or
that white pixels are "nothing" and black pixels are "something". Or
maybe they should be the other way around?

None is None. It is what it is, and that is it's value. What *meaning*
you put to that is up to your program. It is a convention, a useful
convention but still merely a convention, that None is used to represent
values which otherwise would be missing, if there could be actual holes
in Python code.

Same with
object(). I now understand why the only way to describe the object
int(2) is requires using str/repr

Not true.
... print "x has the value two"
... elif x == 3:
... print "x has the value three"
...
x has the value three


At no stage did I call str() or repr() on x.

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".

Expressions always evaluate to objects (unless they don't return at all).
The value of an expression is the object it evaluates to. What is wrong
with that claim? Why do you believe that we need a more complicated,
convoluted understanding of value? What problem are you trying to solve?


--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFJKXWVdjdlQoHP510RAicmAJ4wfDJFA1AXJ9GN/KzWCJ5Mn+sSEQCfScYa
xKK/Tu1cM/eLIonjrGAGVTs=
=xdOd
-----END PGP SIGNATURE-----
 
S

Steve Holden

Derek Martin wrote:
[some stuff, followed by about 32k of unnecessarily quoted crap]

It would be helpful if you'd take the time to trim your replies
appropriately.

regards
Steve
 
S

Steven D'Aprano

It's trivial to show that this is not necessarily the case -- you just
haven't thought of all the ways in which a difference might matter to
you..

Suppose that one of the 10-dollar bills had a serial number which was
never printed by the government (i.e. it is counterfiet). Are they
still the same in every way that you care about?

Derek, I realise that this is the Thread From Hell That Just Won't Die,
but you really should make an effort to read all of it before jumping
into the middle of it. You're not saying anything that I haven't already
said. I'm happy to have reasoned support from others, but you're arguing
with the wrong guy: I've been saying that "the same value" of two objects
is context-dependent since earlier in this thread than you have.

And let me repeat Steve Holden's comment about unnecessarily quoting text
you aren't responding to. (Approximately) 260 lines of dead text at the
end of your post is excessive and rude. Please trim it in the future.

[...]
 
A

Antoon Pardon

No, I was countering the argument that "call by value"
is short for "call by copying the value". I was pointing
out that the inventors of the term didn't use any such
words.

That doesn't counter that that was intended.
Arguing that their words were intended to imply copying,
as part of the essence of the idea, is making an even
bigger assumption about their intentions, IMO.

In their document assignment was a copying.

IMO the bigger assumption is to assume that these people
wanted to define "call by value" for languages which
would have different assignment semantics than their
own.
Rather it seems to me that the essence of the idea they
had in mind is that call-by-value is equivalent to
assignment.

In their particular context.
Furthermore, I don't seem to be alone in coming to that
conclusion -- the designers of other dynamic languages
appear to be using the same logic when they describe
their parameter passing as call-by-value.

So what. Some designers do and some don't and some
make a particular effort to do different.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,768
Messages
2,569,574
Members
45,048
Latest member
verona

Latest Threads

Top