why cannot assign to function call

Aaron Brady castironpi at gmail.com
Mon Jan 5 21:01:55 EST 2009


On Jan 4, 1:28 am, Steven D'Aprano <st... at REMOVE-THIS-
cybersource.com.au> wrote:
> 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

Hi, a bit behind in the discussion.  (What'd I miss?)

I think it would be funny in math if someone said, "No, the answer is
*that* five, not this one," or "Don't use that five, use this other
one."  You can use either one.

Containers are funny in Python in that 'a in a' can be true.  It can't
in real containers.  Also true in  'a in b  and  a in c  and  b is not
c' (and 'b not in c' technically).

About the porch, you could rearrange some of the boards into a swing
or porch door or something, and it's not the same; even though you
have the same boards.  In the Grandfather's Axe story, you could
divide the blade into two, and reattach both halves.  It's the same
material, but in a different configuration.

And here's a funny example of the usage of 'same'.
-- X and Y have the same teacher.
-- X and Y have the same shower curtain.
-- X and Y have the same car.
-- X and Y have the same shirt.
-- X and Y have the same shirt on.

Do you think that context determines the meaning of all of these; that
is, that they never lead to confusion?  Do you think they're common to
say, or do people find other ways, to avoid confusion?  The meaning of
'same' varies from one to another, without syntactical markings.

I want to conclude that 'equality' and 'identicality' (sharing an
identity) are two of the meanings of same, and closely related enough
that they can be confusing for neophyte programmers.  'J and K are not
the same, just the same.'

I think earlier, when John said, you have to keep an eye on the porch
to know if it's the same between two points in time, he was observing
that 'id([])==id([])' can be true.  The porch was secretly wrecked and
rebuilt overnight.

'Same' isn't too far down in frequency (U.K. corpus).
http://ucrel.lancs.ac.uk/bncfreq/lists/2_2_spokenvwritten.txt

> 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

Yes, and it's even possible that multiple objects could exist in the
same place, such as in a copy-on-write.

> 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

It's common enough to say, 'He's not the same person around his
parents.'

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

Surely.  But what if you remove them, and exchange them with new
drawers?

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

Yet, you could comfortably say, 'The team's not the same without
Michael Jordan (star player)'.

I don't think identity is indestructible.  Over the years, the
ballpark, name, uniform, fan base, manager, owner, and players have
*all* changed.  Not the same.

There's a famous psychology example about a brain injury, after which
the subject's friends said, 'He's not the same man anymore', and 'It
just isn't him.'  I don't remember if they (his friends) were native
speakers or not.



More information about the Python-list mailing list