Make coerce working within items rule

[oev81]

Case example:
schema = {'things': {'type': 'list', 'items': [{'coerce': int}, {'coerce': str}]}}

[funkyfuture]

thanks for this extension!

one thing isn't clear for me. the docs state regarding the items rule:

The items will only be evaluated if the given iterable’s size matches the definition’s.

Is this also addressed in this normalization context?

i'd like to see a test that covers the case when a value in a document throws a ValueError on coerce. the handling seems covered. yet error handling deserves some regession tests, especially the error representations.

[funkyfuture]

why is type being called here?

[oev81]

Hi!

i'd like to see a test that covers the case when a value in a document throws a ValueError on coerce.

I've added tests for ValueError and TypeError.

why is type being called here?

I used __normalize_sequence as a base. This line is added by commit eb24176 (Ensures container types are preserved in normalization). If tuple passed instead list, type will be preserved.

>>> schema = {'things': {'type': 'list', 'items': [{'coerce': int}, {'coerce': str}]}}
>>> validator = Validator(schema)
>>> validator.validate({'things': ['1', 2]})
True
>>> validator.document
{'things': [1, '2']}
>>> validator.validate({'things': ('1', 2)})
True
>>> validator.document
{'things': (1, '2')}

[funkyfuture]

a'ight, cool.

I used __normalize_sequence as a base.

ah, thanks for the reminder. ;-)

just one thing, that should be a simple: when the number of fields in a sequence of a documnet is different from the amount of defined items in the relating items constraint, no normalization should be applied as this part of the document will fail later. does this make sense?

[oev81]

does this make sense?

Well... It seems I understand now why you asking :)
I'm playing with cerberus less than a week. I'm learning its features while making a prototype for some real API validation. And that is how I have run into case, when coerce not working. I searched a way to convert some parameter value within a validation, and the only way I found is coerce rule. This rule is applied before validation, and now I've understood that it works only for simple cases, and doesn't work for cases with rules like oneof_schema or oneof_items, or so.

So, is there alternative to coerce? Some workaround?

Answer for your question is, yes, lengths must match :)

[funkyfuture]

now, i don't get your question. due to lack of context. but i'd recommend StackOverflow for such questions.

regarding the length match; there's just a condition missing in line 688 to address this, right?

oh, and one possibility isn't covered: when an items and a schema rule are defined on a field. this may not be common but is valid. it's not hard to change the logic, but the question is in which order these would be applied. both possible orders would make sense in different contexts. :-/

[funkyfuture]

@oev81 are you going to finalize this patch?

[oev81]

are you going to finalize this patch?

@funkyfuture, sorry for not answering. I found the approach of coerce (conversion before validation) does not feet my task (conversion after validation, or conversion within validation).
I'm not interested in the patch now.
Please, drop the patch, if you don't need it.

[funkyfuture]

@nicolaiarocci would you re-open this pr and assign me to it? i'd complete this blind spot some day.