Explanation of list reference

Steven D'Aprano steve+comp.lang.python at pearwood.info
Sat Feb 15 07:44:08 CET 2014


On Fri, 14 Feb 2014 20:24:20 -0800, Rustom Mody wrote:

> In the case of physical objects like dice there is a fairly
> unquestionable framing that makes identity straightforward --
> 4-dimensional space-time coordiantes. If the space-time coordinates of 2
> objects are all equal then the objects are identical, else not.

That simply is not correct. 

(1) General relativity tells us that not all observers will agree on the 
space-time coordinates of two objects, since not all observers agree on a 
single frame of reference.

(2) Quantum mechanics tells us that objects are not located at a single 
space-time coordinate. Objects are "smeared out" over space (and time). 
We cannot really talk about the location of an object, but only about the 
probability of a measurement registering the object at a certain location.


> Now we analogize the space-time identity of physical objects to computer
> identity of computer objects (so-called) and all sorts of problems
> ensue.
> 
> To start with we say two objects are identical if they have the same
> memory address.

Not quite. We say that two objects are identical (that is, that they 
actually are the same object) if they exist simultaneously, in the same 
process, and have the same ID. Normally we don't bother to say that they 
must be in the same process, as that is implied by our understanding of 
how computers normally work.

In fact, even the above is a simplification, since processes may share 
certain objects. This is why Python prohibits Ruby-style monkey-patching 
of built-in types. If we could add or remove methods from (say) lists, 
that could affect more than one Python process.

But ignoring complications like that, we can say that for a wide range of 
implementations, the condition "two objects exist at the same time and 
have the same ID" is equivalent to saying that they exist at the same 
time with the same memory address.


> Then what happens to the same memory address on different computers? If
> you say nothing on two different computers are identical then how do you
> define the correctness of a serialization protocol?

I would not expect that the None object running on my computer is the 
same None object running on another computer. None is a singleton *within 
a single running process*, not over the entire universe of Python virtual 
machines.


> And is 'different computer' even well-defined? Think of clusters, COWs
> NOWs, and other beasties ending in the cloud...

But for all of these things, we can create the abstraction of "a single 
process running at a single moment". True, observers in orbit around a 
black hole a thousand light-years away will disagree about that single 
moment, but we're not talking to them and don't care what they think.


> IOW when we analogize 4-dim infinite space-time into the confines of 'a
> computer' weve bought bigger problems than we disposed off, because
> 
> - for space-time it is unreasonable to imagine a larger frame into which
> that is embedded
> 
> - for computers that larger frame is a key part -- starting with the
> fact that you and I are having a conversation right now
> 
> tl;dr Analogizing physical objects to computer 'objects' is a mistake

Over-philosophising abstractions without the sanity check of what happens 
in real life is an even bigger mistake.

You may or may not choose to lie awake at night obsessing whether 
changing a tyre on your car makes it a different car (see the paradox of 
the Ax of my Grandfather), but the rest of us are too busy actually 
programming to care about such edge cases. They make good discussions for 
a philosophy class, but 99.999% of the time, the abstraction of computer 
objects being like physical objects is a good one.

If you want to demonstrate the fact that this abstraction sometimes 
leaks, you don't need to concern yourself with cloud computing, shared 
process memory space, or any such thing. You just need to recognise that 
objects can contain themselves:

py> L = []
py> L.append(L)
py> L in L
True


Of course, if you are a fan of the Doctor Who television show, you won't 
be concerned by this. If the TARDIS can materialise inside itself, then 
there isn't any problem with lists containing themselves either.



-- 
Steven



More information about the Python-list mailing list