best way to compare contents of 2 lists?

norseman norseman at hughes.net
Fri Apr 24 15:41:13 EDT 2009


Steven D'Aprano wrote:
> On Fri, 24 Apr 2009 10:39:39 -0700, norseman wrote:
> 
>> Technically, ==  is reserved for identical, as in byte for byte same
> 
> Really? Then how do you explain these?
> 
>>>> u'abc' == 'abc'
> True
>>>> 1 == 1.0
> True
>>>> 2L == 2
> True
>>>> import decimal
>>>> decimal.Decimal('42') == 42
> True
> 
> 
> Here's one to think about:
> 
>>>> d1 = {-1: None, -2: None}
>>>> d2 = {-2: None, -1: None}
>>>> print d1, d2
> {-2: None, -1: None} {-1: None, -2: None}
>>>> d1 == d2
> True
> 
> If d1 and d2 are equal and both are dictionaries with the same keys and 
> same values, why do they print in different orders?
> 
> 
> 
=============
(How do I) ...explain these?
   Python cooks the test function.
   That explains a few things I thought were kinda weird.

...one to think about:
Either someone has a programming glitch or else likes stack use.
LoadA push, read-LILO, readB, compare, loop to read-LILO.
And they decided to just pre-load as a matter of course, but maybe 
forgot to read-LILO in print... ie.. didn't finish cooking print.
(or left it out as a reminder or....)

Technically, ==  is reserved for identical, as in byte for byte same
(when == is used to check identical, uncooked)


As a matter of self - I don't favor cooking. I prefer 'cooked' things 
have a different name so I can get what I want, when I want.
Choice on wall:
   fish, deep fried in light beer batter
   sashimi

in case you didn't notice - cooking takes longer :)

I can get the sashimi and take it home and BBQ it, I can roast it, I can 
steam it, I can wok it,..., but the other is what it is. (greasy)

Besides, who says I like your cooking?  :)

Steve



More information about the Python-list mailing list