Fix bug with [False] and [0] equal

[nomnoms12]

#686
Hey. I tried to fix the error. Hope this helps.

An additional isinstance check is needed because Python considers [False] and [0] equal.
I also had to remove the sort to avoid comparison errors.

[Julian]

Hi! Thanks! Very happy to see you take a shot at this.

We need to add a test for this upstream to the test suite (here: https://github.com/json-schema-org/JSON-Schema-Test-Suite) so the first step here is to add one to that. You can test out whether that test exercises the bug by adding it directly to the json directory here in this repository -- that directory is just a literal copy of that test suite git repository.

Also, as for the fix itself, I suspect what we have in your diff will fix the specific instance @Zac-HD found (thanks to him as usual :), but intuitively seems unlikely to be correct I think -- it will likely fail again once a single additional layer of nesting is introduced. In order to fix it once and for all, the code in this area essentially tries to do lots of lazy unwrapping -- but give it a shot with both adding a test and then adding one that's doubly nested, I think you may see the trick here.

[Zac-HD]

@Julian - you might want to steal my encode_canonical_json() function; it serialises JSON objects to strings which are equal if-and-only-if JSONschema considers the objects equal. Not suitable for runtime use where performance is an issue, but it's great for testing!

[nomnoms12]

@Julian Hello again :)

I tried to fix this error by implementing breadth-first search algorithm to apply the unbool function to every element in the container. In code, this looks pretty complicated because I had to process dictionaries and lists at the same time, but the implementation is non-recursive and I think it should be better than dumping to a string.

I'd love to hear what you think about it.

[Julian]

Thanks! Will have a look -- one immediate thing that pops out though is that jsonschema supports arbitrary container types (via TypeChecker) so we can't type check on list and dict concretely -- we'd in theory have to use the collections.abc types.

If the existing implementation doesn't fail on some test (which it seems it doesn't), we probably should add a test (now just in this library, not upstream) to make sure we don't forget that we can have any type there, not just lists and dicts.

But will look more closely at the strategy you used, and definitely thanks again for trying to tackle this.