[Edu-sig] looking for explanations... globals dynamic dict

[Carl Cerecke]

At the risk of boring the other readers....

Yes. You are right. But so was I (on the second time around):

a=1
b=1

a and b could refer to the same object or different objects with the same
value. It depends on implementation details. I agree here.

a=1
b=a

a and b refer to the *same* object here regardless of implementation.
Massimo said they were different, because b+= 2 doesn't change a. That
statement is incorrect.

That's really all I was trying to say. I wasn't trying to be philsophical
about Platonic singleness in the universe or whatever.

Cheers,
Carl.

On 29 March 2011 13:02, Laura Creighton <lac at openend.se> wrote:

> In a message of Tue, 29 Mar 2011 11:49:08 +1300, Carl Cerecke writes:
> >--20cf307abcff67e7bc049f92c049
> >Content-Type: text/plain; charset=ISO-8859-1
> >
> >Yes. Laura, you're correct. I'll try again:
> >
> >Massimo was trying to say that after:
> >a = 1
> >b = a
> >
> >b and a refer to *different* 'one's because changing one of them (b += 2)
> >doesn't change the other.
> >
> >This isn't true. They refer to the same 'one' object (regardless of pytho
> >n
> >implementation). b += 2 doesn't change the 'one' object, but simply point
> >s b
> >to a 'three' object.
> >
> >There. How's that?
> >
> >Carl.
>
> Incorrect, I think.  When I am talking about 'the same 'one' object',
> what I mean is not some sort of philosophical one-ness, some Platonic
> ideal of one, which like all the numbers, is a singleton, wherever it
> occurs in the universe.  I mean something much more concrete than
> that.  Somewhere in my computer are addressable pieces of memory, and
> in those locations are values.  When I say that two variables are
> bound to the same object I mean they refer to that exact same piece of
> memory right there.  (We will ignore, for the purpose of this
> discussion, issues related to garbage collectors that move objects
> around.  Because its the job of the gc writer to make sure that after
> the collection happens, all of those references to the old memory
> location all point to the new memory location.  So the location is
> different, but the property that all variables bound to the same object
> get the same location in memory remains true.)
>
> Consider what happens when your memory goes bad.  Stray alpha particle, or
> (more likely) just a bad bit of memory.
>
> I've typed:
>
> >>> w = 1
> >>> y = 1
> >>> z = 1
>
> suddenly, a bit of memory goes bad, the chunk that w is bound to. Instead
> of containing 1, it contains 2.
>
> What happens?
> Well, in CPython, w is now bound to the value 2.  So is y and z.  And
> I will bet that CPython will fall over and die a horrible death.  All
> the places where it internally uses the value '1' will get the wrong
> value.  But this is an implementation detail.
>
> But in PyPy, when the chunk that w is bound to goes bad, y and z, which
> were bound to entirely different pieces of memory, still have good values
> in them.  Assuming that w is not something that PyPy uses internally, it
> is entirely possible that things could go on seemingly fine.  Should w
> be in the code you typed at an interactive PyPy interpreter, you may be
> amazed and perplexed when you type:
>
> >>>> w = 1  # that memory location goes bad right now!
> >>>> w + w
> 4
>
> Not the result you expected.  You'd complain pypy was broken, and if
> it kept happening (i.e. it was a bug, not bad memory) you'd be correct.
>
> ---------------
> What I think you are trying to say is that you cannot change the values of
> immutable objects.  Which is very true. (Barring disasters with bad memory
> and alpha particles and the like.)  But this has nothing to do with how
> many immutable objects share the same value.  It has to do with the fact
> that you cannot mutate immutable objects.
>
> >>>> a = 1
> >>>> a = 2
> >>>> a = "horseradish"
>
> All I have done is changed a's bindings.  No walking out to memory, making
> a
> chunk of it mean '1', and binding a to it, then walking about again,
> finding
> the same bit of memory, and scribbling on it so it means '2', and then
> walking out and scribbling on it to mean 'horseradish'.  That doesn't
> happen.
>
> as opposed to:
>
> >>>> a = [1]
> >>>> b = a
> >>>> a.append(2)
> >>>> b
> [1, 2]
>
> a.append(2) really did walk out into memory, find the bit that a was bound
> to, and scribbled on it so that where it once said [1] it now says [1, 2]
> Since b is bound to the same bit of memory, it changes too.
>
> Laura
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20110329/1e604970/attachment-0001.html>