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

Validation for colander.Mapping() too liberal #8

Open
deno opened this issue Apr 18, 2011 · 1 comment
Open

Validation for colander.Mapping() too liberal #8

deno opened this issue Apr 18, 2011 · 1 comment

Comments

@deno
Copy link

deno commented Apr 18, 2011

In colander/init.py:405-412 (class Mapping(SchemaType)) there's this validation procedure:

def _validate(self, node, value):
    try:
        return dict(value)
    except Exception, e:
        raise Invalid(…)

The problem is that dict.init will convert to dictionary almost anything:

|  dict(iterable) -> new dictionary initialized as if via:
|      d = {}
|      for k, v in iterable:
|          d[k] = v

Which means that all of these validate correctly:

  • dict( "" )
  • dict( [] )
  • dict( () )

This is inconsistent with, for example, behavior of colander.String.
Zero-value list will result in colander.null:

In colander/init.py:793-759 (class String(SchemaType))

def deserialize(self, node, cstruct):
    if not cstruct:
        return null

And any([bool( [] ), bool( {} ), bool( "" ), bool( set() ), bool( frozenset() )]) => False

I'd like to propose to either check explicitly for dict-like functionality (setitem, getitem), or to at least make the behavior consistent with colander.String (“if not cstruct” instead of “if cstruct is null” in colander/init.py:456).

@jayd3e
Copy link
Contributor

jayd3e commented Mar 19, 2013

All of those types(lists, strings, sets, frozensets) all implement getitem/setitem, so we can't explicitly check for those. So should we just allow a 'dict' to pass through?

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

No branches or pull requests

2 participants