Added test for multipleOf (92.6 shall pass multipleOf 0.1)

[vlcinsky]

    modified:   json/tests/draft4/multipleOf.json

[Julian]

As I mentioned in #185, this is a float deserialization thing. If you want this to pass, use decimals when deserializing. Feel free to add more info (there) if you disagree.

[vlcinsky]

@Julian I am learning from this issue (now I know how to deserialize JSON using decimals).

But I disagree with rejecting this pull request.

You claim, that properly parsing JSON document shall lead to expected result for validating multipleOf.

All what I did was adding just JSON document. And the test fails when it shall not.

What can be done with this problem? I see few options:

• modify test case (Python code) to load numbers as decimals. Then it shall pass provided JSON based test cases.
• alternatively add to JSON document for testing schemas a property: float_deserialize and for this test add decimal.Decimal. Python code would have to respect this property for parsing JSON and pass the test.
• assume, that using float for evaluating rule multipleOf is simply so tricky, that it shall be considered an error and raise an exception stating "rule MultipleOf requires floats being deserialized as decimal.Decimal".
• as before, but do not raise an exception, but print warning.

I am not sure, which of the options seems the best.

[Julian]

It's not a question of "properly" parsing. Floats are floats, they have advantages and drawbacks. The default for loading JSON should not be decimals, it should be floats, for many reasons, which is why json.load does what it does. The fact that this causes issues with JSON Schema's multipleOf is something that people just need to know when dealing with JSON numbers, and if they want to check for divisibility of floats they need to know how that works and what caveats it has.

If you want to add a test for divisibility of decimals that'd be fine with me, although I think one already exists (it'd be in the test suite for jsonschema itself, not what you see in json which is the language agnostic test suite for JSON Schema the specification, since this behavior is something about how you deserialize JSON, not how you validate it).

Of course I'd never turn down documentation or a note in it reminding people of how floating points affect this validator (there might be one already?), but neither of "change the default to decimal.Decimal" or raise an error / warning is acceptable behavior IMHO.