Explanation of list reference

Rustom Mody rustompmody at gmail.com
Sat Feb 15 12:30:52 EST 2014


On Saturday, February 15, 2014 10:32:39 PM UTC+5:30, Roy Smith wrote:
> Steven D'Aprano :
> > > Object identity is simple and well-defined in Python. I don't know why
> > > you are so resistant to this. Read the documentation.

> Marko Rauhamaa 
> > It is not defined at all:
> >    Every object has an identity, a type and a value. An object’s
> >    identity never changes once it has been created; you may think of it
> >    as the object’s address in memory. The ‘is‘ operator compares the
> >    identity of two objects; the id() function returns an integer
> >    representing its identity.

> The "you may think of it as the object's address in memory" part is 
> misleading, and should be removed from the docs.  While it's true that 
> you may think of it that way, such thinking just leads you to make 
> assumptions which are not universally true.

> I agree with Marko that this is not a definition.  It's a collection of 
> random statements about ids, their use, and some misleading philosophy.  
> Even the part about "... compares the identify of two objects" is kind 
> of funky, since it implies that you do indeed have two objects!

> A definition would be:

> "The identity of an object is an integer which never changes during the 
> lifetime of the object, and which is guaranteed to be distinct from the 
> identities of all other objects with overlapping lifetimes.  A given 
> identity may be reused for objects with disjoint lifetimes".

> That (I think) says everything is which is guaranteed about identities, 
> and nothing more.  Once you've defined what an identity is, then you can 
> go on to describe some fun things you can do with it:

Thanks! -- Nice to hear slightly more philosophically astute attempt than
the naivete going around: "Object?! We all know whats an object!
Everyone knows whats an object!!"

However I am betting that the problem remains. Youve transfered the identity 
question into the lifetime.

Now define object-lifetime without reference to identity :-)

[Incidentally same applies to Ian's attempt at reducing identity to creation]

Just staying with 'lifetime' and the original meaning from which this word
was analogized. (Allegorized?)

I am supposed to be about 50 years old.
What exactly does that mean?
The cells in my body recycle every few months -- couple of years if we add bones
The molecules that make up those cells are as old as the universe.

What exactly does that 50 refer to?

> "The id() function returns the identity of an object.  The 'is' operator 
> compares the identities of its two operands and returns True if they are 
> the same."

Thats good -- 'is' in terms of 'id' -- better than the obfuscation and
prevarication of the other way round. Only the name id is misleading -- it
should be machine-id or some such.

Consider these examples:

Two graphs are the same if they have the same no of vertices and
there is a mapping f from one vertex set to the other such that
vw is edge in graph1 iff f(v)f(w) is edge in graph2.

For a mathematician such an identity is unexceptionable
The only catch is that implementing such an identity requires
finding the f and that is NP complete.

Even worse...
Two functions f and g are the same (from a math pov)
if ∀ x y . f(x) = g(y)

Now I define
def f(x) : return x+x
def g(x) : return 2*x

If a python (or any such) implementation could 'solve' 
f==g ∀ f,g, it could also 'solve'
f == h
where h is
def h(x) : return h(x) 
which is the halting problem

Moral?
The meaning of identity is very dependent on framing and has
no 'single' 'obvious' 'most natural' answer.
Given that we are (hopefully!) programmers, a machine-oriented framing seems 
appropriate



More information about the Python-list mailing list