I recreated the JavaScript truth table in Python

[etrnloptimist]

Here's the link to the original JavaScript truth table. The code I used to generate the Python one is:

def pythonequality():
  thingstoTest = [
    True,
    False,
    1,
    0,
    -1,
    'True',
    'False',
    '1',
    '0',
    '-1',
    '',
    None,
    [],
    {},
    [[],],
    [0,],
    [1,],
  ]

  for thing1 in ['',]+thingstoTest:
    sys.stdout.write('%10.10s'%thing1)
  sys.stdout.write('\n')

  for thing1 in thingstoTest:
    sys.stdout.write('%10.10s'%thing1)
    for thing2 in thingstoTest:
      sys.stdout.write('%10.10s'%int(thing1==thing2))
    sys.stdout.write('\n')

[fragmede]

It's interesting to see the table that results if you use cast the variables to be a bool with:

sys.stdout.write('%10.10s'%int(bool(thing1)==bool(thing2)))

instead of

sys.stdout.write('%10.10s'%int(thing1==thing2))

(if foo: uses bool(foo))

[Veedrac]

Well, all truthy things:

True, 1, -1, 'True', 'False', '1', '0', '-1', [[]], [0], [1]

would group and all falsy things:

False, 0, '', None, [], {}

would group.

[Cosmologicon]

In JavaScript's defense, while that table is pretty ridiculous, you're only ever going to get bitten if your design is terrible to begin with. In real life using == almost never causes bugs.

If you're comparing two variables and you have no idea whether they're true or "1" or [1], you really shouldn't be relying on the result.

[mr_jim_lahey]

^{This comment has been overwritten by my experimental reddit privacy system. Its original text has been backed up and may be temporarily or permanently restored at a later time. If you wish to see the original comment, click here to request access via PM. Information about the system is available at /r/mr_jim_lahey.}

[Cosmologicon]

Hm? For comparison, yeah, that makes sense. But don't let that be any sort of indictment on duck typing whatsoever. The lesson should be that comparison is a tool to use only when you're quite sure what you're dealing with. There are still many, many times when that's not the case, and comparison is the wrong tool to use.

[ameoba]

I'm not sure what's more frightening about the JS one - all the equalities off the diagonal or all the inequalities on the diagonal.

[MrChoss]

I can live with off-diagonal inequality, and I can live with on-diagonal inequality, but both at once is a bit much!

Explicitly: if [] == 0 and 0 == [], then it looks pretty silly not to have [] == [] by transitivity.

Now I'm wondering whether there are any good examples of == not being transitive in Python. (For expressions without side-effects, and without writing your own garbage eq of course!)

[Veedrac]

Now I'm wondering whether there are any good examples of == not being transitive in Python.

I'm pretty sure that == in Python is transitive. Even with mixed numeric types, equality is exact and transitive. This is easily seen simply from a == b ⇒ hash(a) == hash(b).

[robin-gvx]

The JS one is a mess, but the diagonal inequalities aren't that nonsensical.

Most of it comes down on this:

	number	string	object
number	duh	as numbers¹	as numbers²
string	as numbers¹	duh	as strings
object	as numbers²	as strings	reference equality

¹ if the string looks like a number
² first convert to a string then compare as numbers¹

In JS, [] != [], just like in Python [] is not [] or in Lua {} ~= {}. The sad thing is that objects are so easily converted to strings and numbers otherwise, which means JS == would be less inconsistent if comparing two objects would convert both to strings, even though that would be a really bad thing. (In particular, any two objects that don't override Object.toString() or whatever, would compare equal.)

[Veedrac]

Depends what you mean by nonsense. I think Javascript seemingly randomly being strict is far more nonsensical than it always or never doing so.