Auch. Quite a few of these stem from the design mistake to allow cross-type equality tests combined with a hard headed effort to try to make it work.

  >>> 2 == 2L
  True
  >>> hex(2) == hex(2L) 
  False
  >>> type(2)
  <type 'int'>
  >>> type(2L)
  <type 'long'>
  >>>

Try the same with Python 3.x, it's an invalid syntax thanks to 'L'.

Didn't JavaScript partially solve the == problem with ===?

Unless they grabbed that from another language as well. And that all being said, the equivalence table for JavaScript is crazy.

There should probably be a javascript version

Language inconsistencies and questionable decisions is why I use my own language whenever I can. When something is wrong, I just fix it. The end result is that it is therefore ugly, stupid and mean for everyone else though.

> The principle of least surprise is not for you only. The principle of least surprise means principle of least my surprise.

- Matz, the inventor of Ruby

Thanks, didnt know they already had one

== is most funny operator of all time. My prefered:

.1 + .2 == .3 \\false

[] == false \\true

but {} == true \\false

All of those have a sane reasoning though.

0.1+0.2 is in fact, not equal to 0.3. it is equal to 0.30000000000000004. Floating point numbers aren't exact and you shouldn't expect them to be.

When comparing things to a boolean that thing gets cast to a boolean. This is by design. bool([]) evaluates to False, so obviously False==False returns True. Same goes for your last example, bool({}) evaluates to False, after which False==True obviously returns False.

Now whether or not you like the way those works, that's how it works by design and is hardly unexpected, except if you're unfamiliar with the language.

> that's how it works by design and is hardly unexpected

Not only that but also very useful (checking if a list a is not empty is easy to read for instance (if a:...))

Well except the first example which is an annoying fact of life.