3 ms·
I find this behavior surprising: >>> d = {0: "int"} >>> d[False] = "bool" >>> d {0: 'bool'} >>> nan = float('nan') >>> d[nan] = 0 >>> d[nan] = 1
by mrgriffin 9y ago
I find this behavior surprising:
>>> d = {0: "int"}
>>> d[False] = "bool"
>>> d
{0: 'bool'}
>>> nan = float('nan')
>>> d[nan] = 0
>>> d[nan] = 1
>>> d
{0: 'bool', nan: 0, nan: 1}
Yes, yes, it's because issubclass(bool, int) == True, and nan != nan, but weird.
And if we include Python 2 you get the truly ridiculous:
>>> dict() < set()
True
>>> dict < set()
False
>>> 0 < dict
True
>>> 0 < 1j
TypeError: no ordering relation is defined for complex numbers
To compare e.g. a dictionary and set we compare the _names_ of the types! Except complex numbers, because they don't have an ordering. I actually have come across this as a bug in production.
Personally I'd just make any comparison involving different types an error. That probably interacts poorly with subtyping, but it's a price I'm willing to pay.
- guitarbill 9y agoThe `nan` thing is actually because `float('nan')` can (and does) return a new object (well, with a different ID) each time. So it's like going `d[object()] = 'a'; d[object()] = 'b'` and not retaining the objects for lookup. > Personally I'd just make any comparison involving different types an error As you point out, this is what Python 3 did for `None`. But it's been idiomatic to have 0 = False when languages didn't have `False`; so `bool(0) == False` makes sense, but also `sum(boolean for boolean in sequence)` works. So you could argue that for `True` and `False`, meaningful coercion is possible, and in reverse, if zero is false-y and everything else is truth-y (like in C), then that also makes sense. Imagine if you had to cast every number to a boolean explicitly! So I guess having `d[0] == d[False]` is the lesser of evils.
- moomin 9y agoMy favourite of these is Haskell > "" = [] True Which makes perfect sense if you know any Haskell, but looks like a JavaScript wat if you don't.