merged and approved

fyi ya can do (1..=n) instead (1..n + 1) to include the end of the range

In the test cases and sample tests for Python, the parameters to assert_equals are being given in the wrong order. It should be test.assert_equals(is_possible(expr),expected_value). As it is, if the user's solution returns True when False is expected, it will say False should equal True, when it should say True should equal False.

I've put togeather a JavaScript translation. Could you please review it?

(I've left description as is and translated the test cases directly.)

I wouldn't say it's bad to try and generate all combinations.
In fact there are interesting things you can do with the logic engine that generates possible solutions to an expression.