Wrong keys exception can point at the wrong (wrong) keys

[sjakobi]

With the current master:

>>> s = Schema({And(str, Use(str.lower), 'id'): int})
>>> data = {'Id': 10, 'Name': 'me'}
>>> s.validate(data)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/simon/src/schema/schema.py", line 152, in validate
    e)
schema.SchemaError: Wrong keys 'Id', 'Name' in {'Name': 'me', 'Id': 10}

The problem is that the error message claims that 'Id' is a wrong key although 'Id' has been validated. The only key that hasn't been validated in this example is 'Name'.

This is due to 'Id''s schema, And(str, Use(str.lower), 'id'), which transforms 'Id' to 'id' which results in 'Id' being included in wrong_keys.

In general, this incorrect error message can always appear if key schemas transform their data.

Any ideas how to fix this? Is there a way to compute wrong_keys that is both simple and precise?

[skorokithakis]

I'm not sure this is entirely wrong. For example, you may want to specify case-insensitive keys, so that any capitalization of id would work. This would be a good way to do that. If you want to specify that the starting key should always be Id, you can do And("Id", Use(str.lower)).

[sjakobi]

Using your schema doesn't really change much in this problem:

>>> s = Schema({And("Id", Use(str.lower)): int})
>>> data = {'Id': 10, 'Name': 'me'}
>>> s.validate(data)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "schema.py", line 153, in validate
    e)
schema.SchemaError: Wrong keys 'Id', 'Name' in {'Id': 10, 'Name': 'me'}

'Id', though validated, is still included in the error message, because its schema has transformed it to 'id'.

[skorokithakis]

The idea is that you'd use the final key, "id".

[sjakobi]

I'm afraid I don't quite understand what your proposed solution is. How would you compute wrong_keys?

[skorokithakis]

Oh, I see what you mean now. I was thinking of the way we validate the values, not the keys. I'll have a look at this in more detail later and get back to you.

[sjakobi]

So, I guess the downside to #80 is that we have additional runtime costs to build matched_input_keys even if we don't end up using it at all.

Does anyone see a way of moving the computation to the point where we already know that we're going to have an exception?