I'm answering both John and Aaron's comments in the following. Mostly
John at the start, Aaron toward the end.
On Sat, 03 Jan 2009 15:42:47 -0800, Aaron Brady wrote:
> On Jan 3, 11:25 am, John O'Hagan <resea...@johnohagan.com> wrote:
[...]
> > >According to this, when you replace every floorboard on a porch, one
> > >at a time, it's still the same porch-- it's changed, it's different,
> > >and it's the same. However, if you haul off the porch and put a new
> > >one in its place, it's not. ('porch[:]=' vs. 'porch='.) You can't
> > >just look at the initial and final configurations of matter to
> > >determine so. Therefore, 'id' is an informal function.
> >
> > This analogy describes the "ontological minefield" I was referring to
> > in a previous post in this thread (which has expired in my mail
> > reader, so my apologies if the threading goes awry): In what sense is
> > a porch (or list, or string) the same if all (or even some of) its
> > parts have been exchanged?
> >
> > I think the answer is something to do with the abstraction, the
> > "container", the instance of the class.
That seems reasonable. When you say alist[:] = [1, 2, 3] the container
remains "the same", while the contents change.
> > Would it be fair to say that perhaps there are no
> > truly mutable objects, only immutable containers whose contents (also
> > immutable objects themselves) may be exchanged? Or to pose the
> > question another way, are objects only mutable insofar as they are
> > composite?
That depends on what you mean by composite. Everything is composite in
some sense, even a single bit in memory has a physical reality made of
atoms with magnetic fields. But taken as an abstract entity, it is
reasonable to treat a single bit as an atomic non-composite thing, and a
single bit is mutable.
In practice, actual Python objects tend to be mutable only if they are
composite (although being composite doesn't make them mutable -- consider
frozen sets and tuples). In principle, this is not necessary. There's no
reason why Python couldn't expose a single bit as a data type, so you
could write this:
>>> n = bit(1)
>>> bool(n)
True
>>> n.flip()
>>> bool(n)
False
> > As you argue above, the planks are not the porch; I would add that
> > it's your _decision_ to build (or tear down) a porch which makes it
> > _that_ particular porch (or not).
No, there's no such decision needed. Perhaps a hurricane comes through
and rips the porch up. Maybe a rogue television crew comes by while
you're at work and renovates your house without your knowledge.
The lack of decision-making needed is more obvious when you consider
something like a fast-flowing river. The specific water molecules making
up the river at any particular instant in time flow away in a matter of
days or weeks, but rivers have a continuity of existence measured in
thousands of years. I trust that nobody is going to argue that the river
makes any decisions at all?
> > As you imply above (I think), you have to keep looking (or someone
> > does, presumably the interpreter) to know whether an object is the
> > same as or just equal to another (which starts to sound spookily like
> > the role of "the observer" in phenomenology or quantum physics).
No, I think you're introducing mysticism here that isn't needed. A bit
like quantum mechanics, really :)
In Python, every object has an identity and a value. If objects X and Y
have the same identity, they are the same object. If X is the object with
id 1234, and Y is the object with id 1234, then both are the same object.
If their ids are different, then they are not.
In CPython, the id is given by the memory location of the object, which
leads to a very intuitive understanding of "same": the object with id
1234 is at memory location 1234, and since there can only be one object
at a particular memory location at a time, obviously all objects with id
1234 must be the same object (provided they exist simultaneously).
(To be pedantic, there can't actually be objects [note plural] existing
simultaneously with the same id. There can only be multiple references to
the one object.)
In Python implementations where the id is not a memory address
(IronPython and Jython I think?) the above remains true, even though
there isn't the simple intuitive picture of "only one object can be at a
specific memory address". Python guarantees that the id is *something*
which is guaranteed to be unique over the lifetime of every object.
Actually, our intuition about one thing per place at the one time is not
strictly correct. Consider the memory address 1234, which currently has
the value in hex of 0x58. That byte may be the numeric value 88, the
ASCII char "X", the set of flags 1011000, or any other thing, depending
on what interpretation we give to it. "What a thing is" is actually a
more difficult question than it appears at first glance.
[...]
> I think the key ingredient is that there's no such thing as side
> effect in math.
I don't see that this is relevant. We're not talking about mathematical
equality, but about the more general concepts of identity and sameness.
> In example,
>
> a= [0, 1, 2]
> a[:]= [3, 4, 5]
>
> There aren't many natural language senses in which 'a' is the same
> object as before.
Of course there are.
If I have a box containing three things (a piece of paper with the number
"0" written on it, a plastic block in the shape of "1" and a tally stick
with two notches cut in it), and then I remove those three things and
replace them with something else, it's the same box.
The English and Australian cricket teams have been playing international
Test cricket since 1877. None of the team members playing in 1877 are
still alive today. The entire lineup of both cricket teams has been
replaced repeatedly, and yet they are the same teams.
The same holds for many, many different organisations: churches, armies,
regiments, political parties, social clubs, companies, guilds, nations,
sporting teams, secret societies, criminal gangs, ecosystems, tribes,
communities of many sorts, and so forth.
Far from being rare, this is very common.
> If I have a leg transplant, I'm the same person,
> but if you replace the entire contents of me, I'm not.
Every (?) molecule in your body is replaced over a period of
approximately seven years. Some molecules are replaced much quicker, some
a little slower, but speaking roughly, the entire contents of you is
replaced every seven years. Aaron, are you the same person you were a
decade ago? In some sense, not at all -- you're a different person to the
annoying person who called himself "castironpi" and was repeatedly
accused of being a bot only a few months ago. But in another sense, yes,
you are the same person -- there is a continuity of existence.
See also the Ship of Theseus paradox, otherwise known as My Grandfather's
Axe paradox.
http://en.wikipedia.org/wiki/Ship_of_Theseus
[...]
> The porch is defined by its location, but not exclusively.
If we remove the porch from the house and transport it whole to another
house, it remains the same porch attached to a different house.
> Natural
> language identity is a cluster concept, without strict necessary and
> sufficient conditions. Nothing really presses our boundaries of it
> that much; there aren't many practical questions that lay out the
> facts, then ask, 'But is it the same?' You can replace the porch
> board-at-a-time, and it is; and you can haul it somewhere and it is.
> But rearrange the same boards, and it's not.
I think you overstate your case. If you move the boards around on the
porch, it remains the same porch. Likewise if I have a chest of drawers,
and I take the top drawer and put it at the bottom, the bottom drawer in
the middle and the middle drawer at the top, surely it is the same chest
of drawers? I haven't even replaced anything, just moved them around.
> Continuity of form is
> probably the prevalent feature, which as you state, does break down in
> the case of composite (piece-wise) transformations.
I think continuity of form is an important factor in deciding what is the
same and what is not, but I don't think it is the only one. See for
example the anecdote about the Japanese temple in the Wikipedia article
above. And I think you're wrong to say that piece-wise transformations
break down continuity of form. You are, in some sense, the same person
who some years ago was a crawling baby unable to speak. There are
significant changes and replacements and add-ons that nevertheless don't
break continuity.
> You might get farther comparing container objects to spots on a
> bulletin board. The only thing that goes 'in' a container is a
> denoting phrase to another object (and by the way, not a description);
> the other also has its own spot independently on the board.
That's a reasonable analogy for the implementation of CPython, but it
need not be the only implementation. It wouldn't be fast, or efficient,
or reasonable, but one could create a Python implementation where (for
example) a list didn't just hold pointers to objects, but it held the
actual entire object (no matter how large). Identity could be divorced
from memory location: the one object could exist in many different places
in memory, in the same way that an object can exist in many different
times. The underlying VM would ensure that all such instantiations of the
one object remained in sync at all time.
Such an implementation would be inefficient and foolish, but it would
still be Python.
Having said that, it is perfectly valid to ignore the implementation when
describing how Python operates. It really doesn't matter whether CPython
is implemented like a bulletin board or not, it behaves as if it were,
and that makes it a reasonable analogy.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
