> objects of different types always compare unequal, and are ordered consistently but arbitrarily

Seems like a completely reasonable thing to do?

That's entirely an implementation detail. The thing that matters for programmer experience is the specification of behavior: There's going to be an arbitrary order. You certainly can argue that you think it would be less surprising if trying this just failed, or that promising a stable order ties down implementations too much, but I don't think providing an order is that surprising.

None (as far as I remember) of the common "wat" examples about JS are interpreter implementation details, but specified behavior.

I'm mildly curious why CPython chooses to implement it this way, but if I had to guess: I'm assuming it is to provide a stable order between objects of different classes with the same hash() value. Hash-value being what I suspect is what the quoted answer misrepresents as "their address" (the address being in CPython the default fallback for objects that do not implement a hash() function), and being a good candidate to establish an arbitrary order.

Sorry, I'm not sure I understand at all the difference between this and the 'wat' stuff.

That's just GIGO. There's simply no good way to order "two incompatible types where neither is numeric".

There's always an option to just treat it as an error, especially given that 1+"2" already is.

None of those surprising behaviors exist in python 3.

I wouldn't say "100" < "2" really counts, since, alphabetically it makes sense (an equivalent would be "baa" < "c").

Yes, Python2 was called out explicitly. Reference equality is definitely 'wat' shit IMO, though it's really mainstream too.