why cannot assign to function call

[Steven D'Aprano]

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