Issues with unique item identification about jsonschema HOT 10 CLOSED

Ugh, that first one is going to be a real pain. I'm almost inclined to consider not fixing it. Python's True and False are, for hysterical raisins or not, mostly just 0 and 1 with nice reprs. I know we special case them already for type checking, and that obviously you get those when loading, but I'm curious what is done in languages without booleans like C where the situation is similar.

from jsonschema.

Hehehe, 'hysterical raisins' :D

from jsonschema.

;) not my invention.

from jsonschema.

We could break container down into types and then deal with it:

    type_groups = {}
    for t, i in itertools.groupby(container, type):
        type_groups.setdefault(t, []).extend(i)

EDIT: Not even sure why I used groupby there, artifact of trying to solve the whole problem at once which didn't work due to not being able to sort a list with different types.

from jsonschema.

I think even if we fix this we should probably leave it for now and come
back to it later after we get some more important stuff done.

We have to be careful, bool really is the only special case, which is why
this is pretty sucky. If someone comes up with their own type and hooks it
into json.loads that's up to them, and they should be the ones deciding
which two objects are equal.

On Sunday, October 28, 2012, Chase Sterling wrote:

We could break container down into types and then deal with it:

type_groups = {}
for t, i in itertools.groupby(container, type):
    type_groups.setdefault(t, []).extend(i)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/43#issuecomment-9855054.

from jsonschema.

I also noticed that the 3 tests in uniqueItems that cause this problem are actually just tests from the enum suite: https://github.com/Julian/jsonschema/blob/master/tests/draft3/uniqueItems.json#L54

EDIT: That did make it easy to ignore them all at once though ;)

from jsonschema.

We could cast bools to a custom class maybe. Then any standard unique tests would work.

class Bool(object):
    def __init__(self, bool):
        self.bool = bool
    def __eq__(self, other):
        return other.__class__ == Bool and self.bool == other.bool

container = map(lambda x: Bool(x) if isinstance(x, bool) else x, container)

from jsonschema.

That would be closer to what we'd have to do, yeah. I'm still thinking about whether we should though, and leaning towards shouldn't. In fact I'm even considering we should revert the special casing in is_type and have {"type" : "integer"} validate true. But hey, it's still early in the morning. Let me know what you think. I think we'd confirm on the ML because I still am curious what languages without booleans do.

What I definitely do want to do though is make this a failing test rather than an error. So I think we should simplify the test in enum to not cause this error, and add another test (for now in optional) that is specifically testing for this behavior.

from jsonschema.

I think I'm more inclined to fix it. The one case I can see happening, is somebody is allowing multiple forms of true/false in their schema with {"enum": [true, false, 1, 0]} and then all of a sudden their schema isn't usable with jsonschema, since it won't pass our metavalidation.

from jsonschema.

Possibly cleaner solution, less object creation at least:

true = object()
false = object()

def transform_booleans(o):
    if isinstance(o, bool):
        return true if o else false
    return o

container = map(transform_booleans, container)

from jsonschema.