Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove ITERABLE type validating. #160

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Remove ITERABLE type validating. #160

wants to merge 1 commit into from

Conversation

Exahilosys
Copy link

There's no need to automatically type check ITERABLE flavours when this can be done by the user.
The reason this is needed is because different iterables can often be treated the same way.
For example, the default JSON encoder accepts both tuples and lists as array types.
Creating a schema with either of them will result in the validation failing if the other is passed instead.

There's no need to automatically type check ITERABLE flavours when this can be done by the user. 
The reason this is needed is because, for example, the default JSON encoder accepts both tuples and lists as array types.
Creating a schema with either of them will result in the validation failing if the other is passed instead.
@skorokithakis
Copy link
Collaborator

Hmm, I'm not sure what you mean. Doesn't iterable accept both lists and tuples? I'm confused as to the reasoning behind the removal.

@Exahilosys
Copy link
Author

Consider the following data:

data = tuple(range(1))

And the following schema:

schema = Schema([int])

Validating raises the following error:

schema.SchemaUnexpectedTypeError: (0,) should be instance of 'list'

As .validate automatically validates the iterable's type.
Removing that line of code passes the decision of type validation to the user.
By adding a bit of extra logic in script code, the same results can be achieved:

schema = Schema(And(list, Schema([int])))

All while allowing to further abstractify or even bypass such validation:

import collections.abc
schema = Schema(And(collections.abc.Iterable, Schema([int]))) # abstract
schema = Schema([int]) # bypass

Using list to create the data and (int,) in schema would have the the same error failing for tuple.

This request arose when I tried to validate either tuple or list (without knowing what to expect) against an ITERABLE flavoured schema while working with JSON since the default encoder accepts both.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants