Tuple assignment and generators?

[Dave Hansen]

On 5 May 2006 05:23:24 -0700 in comp.lang.python, "vdrab"
<stijndesaeger at gmail.com> wrote:

>> Are you telling us that you *had* read that doc,
>> and tripped because it says "depending on the implementation",
>> when it should say "at the choice of the implementation" ?
>
>no.
>let's see, where to start ... ?
>let's say there's a certain property P, for the sake of this loooong
>discussion, something
>more or less like a class or type's property of "having immutable
>values, such that any instance with value X has a single, unique
>representation in memory and any two instantiations of objects with
>that value X are in fact references to the same object".

IOW, property P is "(x == y) => (x is y)" (read "=>" as "implies").

Note that only immutable objects can have property P.

>
>Then, for example, python strings have property P whereas python lists
>do not:
>
>>>> x = "test"
>>>> y = "test"
>>>> x is y
>True
>>>> x = []
>>>> y = []
>>>> x is y
>False
>>>>

Note this last relationship is _guaranteed_.  Lists are not immutable,
and therefore can not have property P.

>
>Now, as it turns out, whether or not python integers have property P
>_depends_on_their_value_.

>From the zen, I believe this falls out from "practicality beats
purity."

>For small values, they do. For large values they don't. Yes, I

Even that's not necessarily true.  The implementation is free to
always create a new immutable object, even for small values.

>understand about the interpreter optimization. I didn't know this, and
>I find it neither evident nor consistent. I don't think the above post
>explains this, regardless of how you read "implementation".

Think about implementation for a moment.  Consider the statement

   x = some_arbitrary_integer()

Do you really want the interpreter to go through all the existing
integer objects in the program to see if that particular value exists,
just to guarantee some some later statement

   x is y

returns True if x == y?

OK, maybe we can change the "is" operator on immutable objects such
that x is y returns True if x == y.  But then you can encounter a
situation where "x is y" but "id(x) != id(y)"  Now what?

Perhaps the solution would be to disable the "is" operator and "id"
function for immutable objects.  But then _they_ lose generality.
There doesn't seem to be a way to win.

So it all comes down to "who cares?"  Immutable objects are immutable.
You can't change them.  Object identity is a non-issue.

This is not the case for mutable objects.  Consider

a = [1,2,3]
b = [1,2,3]
c = a

a==b
a==c
b==c
a is not b
b is not c
c is a

c.append(4)

>
>In fact, the whole string of replies after my initial question reminded
>me of something I read not too long ago, but didn't quite understand at
>the time.
>source :
>http://www.oreillynet.com/ruby/blog/2006/01/a_little_antiantihype.html
>
[...whinge elided...]
>
>taking this rant with the proverbial grain of salt, I did think it was
>funny.

Your original post in its entirety (ignoring the example) was "what
the...? does anybody else get mighty uncomfortable about this? "

The first response (paraphrased) was "No.  Why should I?  With
immutable objects, I care about ==, not is."

Your response seemed to want to cast doubt on the integrity of the
entire language: "Given this though, what other such beauties are
lurking in the interpreter, under the name of 'implementation
accidents'?"

>
>Anyway, thanks for all the attempts to show me.
>I will get it in the end. 

I will ignore the double entendre, and simply hope I was of help, and
wish you luck.  Regards,
                                        -=Dave

-- 
Change is inevitable, progress is not.