On 2013-10-10, Roy Smith <r...@panix.com> wrote: > In article <52562ee3$0$2931$c3e8da3$76491...@news.astraweb.com>, > Steven D'Aprano <st...@pearwood.info> wrote: > >> Just came across this little Javascript gem: >> >> ",,," == Array((null,'cool',false,NaN,4)); >> >> => evaluates as true >> >> http://wtfjs.com/2011/02/11/all-your-commas-are-belong-to-Array >> >> I swear, I am never going to complain about Python again. > > I've just finished reading JavaScript: The Good Parts, by Douglas > Crockford (now I'm working on the harder part of re-reading it slowly, > to make sure I really understand it). Anybody who is forced to work > with javascript should read this book. It's the K&R of JS. > > Anyway, one of the pieces of advice he gives is to pretend that == > doesn't exist, and always use ===. PHP suffers from much the same > problem. > > BTW, here's a Python equality oddity: > >>>> r = 0.0 >>>> c = 0 + 0j >>>> r == c > True >>>> int(r) == int(c) > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > TypeError: can't convert complex to int > > If x == y, then f(x) should also equal f(y). More > specifically, if x == y, and x is in the domain of f(), then y > should also be in the domain of f().
Mixed arithmetic always promotes to the wider type (except in the case of complex numbers (Ha!)). r == c is equivalent to r == abs(c), which returns the magintude of the complex number. I wonder why it was deemed reasonable to do that but not for the float constructor to do the same, or even int. > BTW, one of the earliest things that turned me on to Python was > when I discovered that it uses j as the imaginary unit, not i. > All right-thinking people will agree with me on this. On top of the engineering origin, j is more noticeable. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
