Possible bug in MochiKit.Base.compare

[Per Cederberg]

While writing some MochiKit tests, I stumbled upon the following:

#> compare("", [])
==> 0

#> "" == []
==> true

Seems like the JavaScript type coercion is used inside compare():

compare: function (a, b) {
if (a == b) {
return 0;
}
...

But perhaps that was just a mistake? It seems to be at odds with the
idea of a "safe" compare function... If nobody is terribly dependent
on this I'll fix it for 1.5. But please verify this if you are
extensive users of compare().

Cheers,

/Per

[Fredrik]

similarly you also have:

#> compare(0, '')
==> 0

#> compare(0, [])
==> 0

.. But, equivalence is one thing, defining "meaningful" ordering is
more difficult.

A quick take in Python gives this table (didn't check the standard):
----------
>>> '' == []
False
>>> '' < []
False
>>> '' > []
True
>>> 0 < ''
True
>>> 0 > ''
False
>>> 0 < []
True
>>> 0 > []
False
----------------

At least the above defines an ordering, where JavaScript returns false
for any ordering of 0, [] and ''" for example.
More thoughts?

Regards
// Fredrik

[Fredrik Blomqvist]

Some more input regarding comparisons. Found this in the Python 3
changelog: http://docs.python.org/release/3.0.1/whatsnew/3.0.html#ordering-comparisons
Essentially they've decided to tighten the rules, making all the
examples I listed above throw a: "TypeError: unorderable types:"
exception.

Regards
// Fredrik Blomqvist