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
--
http://mail.python.org/mailman/listinfo/python-list
