«

I have spent some time searching for a bug in my code, it was due to
different work of "is" with () and []:
>>> () is ()
True
>>> [] is []
False

(Python 2.7.2+ (default, Oct 4 2011, 20:03:0
[GCC 4.6.1] )

Is this what it should be or maybe yielding unified result is better?
D.

On 20/04/2012 20:10, dmitrey wrote:
> I have spent some time searching for a bug in my code, it was due to
> different work of "is" with () and []:
>>>> () is ()
> True
>>>> [] is []
> False
>
> (Python 2.7.2+ (default, Oct 4 2011, 20:03:0
> [GCC 4.6.1] )
>
> Is this what it should be or maybe yielding unified result is better?
> D.

The reason that "[] is []" evaluates to false is because lists are
mutable and each expression "[]" evaluates to a different object.
Therefore you can change one without changing the other:

>>> a, b = [], []
>>> a.append(None)
>>> a
[None]
>>> b
[]

On the other hand tuples are immutable, so there's no danger in having
each literal () evaluate to the same object - since you can't change a
tuple but only replace a reference to a tuple with a reference to
another tuple, there's no need to have the two "()"s in something like

>>> a, b = (), ()

evaluate to different objects, since there is no danger that one can
affect the value of b by doing stuff to a.

I believe it says somewhere in the Python docs that it's undefined and
implementation-dependent whether two identical expressions have the same
identity when the result of each is immutable, though I can't find the
quotation right now. If my recollection is correct then you probably
shouldn't rely on something like "() is ()" giving the same answer
across platforms.

--
Hate music? Then you'll hate this:

http://tinyurl.com/psymix

dmitrey <> writes:

> I have spent some time searching for a bug in my code, it was due to
> different work of "is" with () and []:
>>>> () is ()
> True
>>>> [] is []
> False
>
> (Python 2.7.2+ (default, Oct 4 2011, 20:03:0
> [GCC 4.6.1] )
>
> Is this what it should be or maybe yielding unified result is better?

Tuples are immutable, while lists are not. Because tuples are immutable,
there is no point in having several empty tuples: one value is enough,
and "is" recognizes this. Lists are different, they can change "value"
(contents), and several names can be bound to the same list (in other
words, you can have side-effects on a list). With:

a = []
b = a
a.append(42)
print b

you get [42]. If instead you do:

a = []
b = []
a.append(42)
print b

you get the expected []. I.e., you need several distinct empty lists,
to make sure they can change value independently.

(In case you wonder: lists in Python are not linked lists of cons-cells,
they are more monolithic structures, and two lists cannot share a common
tail.)

-- Alain.

In article <>,
Alain Ketterlin <> wrote:

> Tuples are immutable, while lists are not.

If you really want to have fun, consider this classic paradox:

>>> [] is []
False
>>> id([]) == id([])
True

On 21/04/2012 01:01, Roy Smith wrote:
> In article<>,
> Alain Ketterlin<> wrote:
>
>> Tuples are immutable, while lists are not.
>
> If you really want to have fun, consider this classic paradox:
>
>>>> [] is []
> False
>>>> id([]) == id([])
> True

Huh. This is not what I would have expected. What gives?

--
Hate music? Then you'll hate this:

http://tinyurl.com/psymix

On Friday, April 20, 2012 12:34:46 PM UTC-7, Rotwang wrote:

> I believe it says somewhere in the Python docs that it's undefined and
> implementation-dependent whether two identical expressions have the same
> identity when the result of each is immutable

I was curious where that might be on my system, and found the disagreement with the ((),) case and up.

(Python 2.7.1, Darwin 11.3.0, GCC 4.2.1)

Am 21.04.2012 05:25, schrieb Rotwang:
> On 21/04/2012 01:01, Roy Smith wrote:
>> In article<>,
>> Alain Ketterlin<> wrote:
>>
>>> Tuples are immutable, while lists are not.
>>
>> If you really want to have fun, consider this classic paradox:
>>
>>>>> [] is []
>> False
>>>>> id([]) == id([])
>> True
>
> Huh. This is not what I would have expected. What gives?

This happens only because the first [] gets destroyed after evaluation
of id([]). The second [] then by accident gets the same id as the first
one had.

>>> a = []
>>> b = []
>>> id(a) == id(b)
False

Greetings

On 21/04/2012 09:46, Alexander Blinne wrote:
> Am 21.04.2012 05:25, schrieb Rotwang:
>> On 21/04/2012 01:01, Roy Smith wrote:
>>> In article<>,
>>> Alain Ketterlin<> wrote:
>>>
>>>> Tuples are immutable, while lists are not.
>>>
>>> If you really want to have fun, consider this classic paradox:
>>>
>>>>>> [] is []
>>> False
>>>>>> id([]) == id([])
>>> True
>>
>> Huh. This is not what I would have expected. What gives?
>
> This happens only because the first [] gets destroyed after evaluation
> of id([]). The second [] then by accident gets the same id as the first
> one had.

Thanks.


--
Hate music? Then you'll hate this:

http://tinyurl.com/psymix

Le samedi 21 avril 2012 10:46:39 UTC+2, Alexander Blinne a écrit*:
> Am 21.04.2012 05:25, schrieb Rotwang:
>
> This happens only because the first [] gets destroyed after evaluation
> of id([]). The second [] then by accident gets the same id as the first
> one had.
>
> >>> a = []
> >>> b = []
> >>> id(a) == id(b)
> False
>
> Greetings

Hi,

I played (python3.2) a bit on that and :

case 1) Ok to me (right hand side is a tuple, whose elements are evaluated one per one and have same effect as your explanation (first [] is destroyedright before the second one is created) :

>>> x, y = id([]), id([])
>>> x == y
True
>>>


case 2) also ok to me:

>>> x = id([]) ; y = id([])
>>> x == y
True
>>>


case 3) NOT ok to me :

>>> x = id([])
>>> y = id([])
>>> x == y
False
>>>


case 4) ok to me :

>>> def f():
x = id([])
y = id([])
return x == y

>>> f()
True
>>>


I'd have thought that cases 2&3 are totally, while 3&4 nearly, syntactically equal and that case 3 is the incorrect result..

how would you explain case 3 vs cases 2 and 4 ??


regards,

gs.

On 2012-04-20, dmitrey wrote:
> I have spent some time searching for a bug in my code, it was due to
> different work of "is" with () and []:
>>>> () is ()
> True

You should better not rely on that result. I would consider it to be
an implementation detail. I may be wrong, but would an implementation
that results in

() is () ==> False

be correct or is the result True really demanded by the language
specification?

>>>> [] is []
> False

Same for that.

>
> (Python 2.7.2+ (default, Oct 4 2011, 20:03:0
> [GCC 4.6.1] )
>
> Is this what it should be or maybe yielding unified result is better?

See above.




Bernd

--
"Die Antisemiten vergeben es den Juden nicht, dass die Juden Geist
haben - und Geld." [Friedrich Nietzsche]