Possible bug in MochiKit.Base.compare

7 views
Skip to first unread message

Per Cederberg

unread,
Oct 28, 2010, 1:00:36 AM10/28/10
to moch...@googlegroups.com
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

unread,
Oct 28, 2010, 9:42:57 AM10/28/10
to MochiKit
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

unread,
Nov 25, 2010, 11:30:09 AM11/25/10
to MochiKit
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
Reply all
Reply to author
Forward
0 new messages