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

'coerce' ignores 'nullable': True #269

Closed
andreymal opened this issue Sep 25, 2016 · 3 comments
Closed

'coerce' ignores 'nullable': True #269

andreymal opened this issue Sep 25, 2016 · 3 comments

Comments

@andreymal
Copy link

@andreymal andreymal commented Sep 25, 2016

>>> v = Validator({'foo': {'type': 'integer', 'coerce': int, 'nullable': True}})
>>> v.validate({'foo': None})
False
>>> v.errors
{'foo': ["field 'foo' cannot be coerced: int() argument must be a string, a bytes-like object or a number, not 'NoneType'"]}

but expected:

>>> v.validate({'foo': None})
True
>>> v.errors
{}
>>> v.normalized({'foo': None})
{'foo': None}

This behavior can be logical (i can set something like 'coerce': lambda x: int(x) if x is not None else None), but I do not think it's convenient, because I have to specify nullable rule twice: in schema and in callable. I think, nullable should be checked first, and if value is None, then coerce callable should not be called.

If it's a bug and if architecture allows to fix this, please fix this :)

If it's a feature, please add a note about nullable in value coercion documentation (better with an example).

@funkyfuture
Copy link
Member

@funkyfuture funkyfuture commented Oct 26, 2016

this is similar to #268.

@belthaZornv
Copy link

@belthaZornv belthaZornv commented Feb 27, 2017

Bump, this makes sense.. is there any possibility to get this?

funkyfuture added a commit to funkyfuture/cerberus that referenced this issue Apr 21, 2017
@sohaibfarooqi
Copy link

@sohaibfarooqi sohaibfarooqi commented Nov 23, 2017

Is this feature released? I am using version 1.1, still facing this issue

nikhaldi pushed a commit to nikhaldi/cerberus that referenced this issue May 2, 2019
Only ignore exceptions if a value for a nullable field is not null.
Previuosly all exceptions during custom coerction were ignored with nullable
fields. The developer and/or user most likely wants to know about
exceptions that happen during coercion - this leads to hard to debug
problems otherwise.

The purpose of the `e is not TypeError` condition was unclear. As far as I
know this condition can never be false (`e` is an instance of an exception,
not an exception class).

I think this is still in line with the original intent of this code, which
was to make common coercions like `float` work with nullable fields out
of the box: pyeve#269
nikhaldi pushed a commit to nikhaldi/cerberus that referenced this issue May 2, 2019
Only ignore exceptions if a value for a nullable field is not null.
Previously all exceptions during custom coerction were ignored with nullable
fields. The developer and/or user most likely wants to know about
exceptions that happen during coercion - this leads to hard to debug
problems otherwise.

The purpose of the `e is not TypeError` condition was unclear. As far as I
know this condition can never be false (`e` is an instance of an exception,
not an exception class).

I think this is still in line with the original intent of this code, which
was to make common coercions like `float` work with nullable fields out
of the box: pyeve#269
nikhaldi pushed a commit to nikhaldi/cerberus that referenced this issue May 2, 2019
Only ignore exceptions if a value for a nullable field is not null.
Previously all exceptions during custom coerction were ignored with nullable
fields. The developer and/or user most likely wants to know about
exceptions that happen during coercion - this leads to hard to debug
problems otherwise.

The purpose of the `e is not TypeError` condition was unclear. As far as I
know this condition can never be false (`e` is an instance of an exception,
not an exception class).

I think this is still in line with the original intent of this code, which
was to make common coercions like `float` work with nullable fields out
of the box: pyeve#269
nikhaldi pushed a commit to nikhaldi/cerberus that referenced this issue May 6, 2019
Only ignore exceptions if a value for a nullable field is not null.
Previously all exceptions during custom coerction were ignored with nullable
fields. The developer and/or user most likely wants to know about
exceptions that happen during coercion - this leads to hard to debug
problems otherwise.

The purpose of the `e is not TypeError` condition was unclear. As far as I
know this condition can never be false (`e` is an instance of an exception,
not an exception class).

I think this is still in line with the original intent of this code, which
was to make common coercions like `float` work with nullable fields out
of the box: pyeve#269
nikhaldi pushed a commit to nikhaldi/cerberus that referenced this issue May 6, 2019
Only ignore exceptions if a value for a nullable field is not null.
Previously all exceptions during custom coerction were ignored with nullable
fields. The developer and/or user most likely wants to know about
exceptions that happen during coercion - this leads to hard to debug
problems otherwise.

The purpose of the `e is not TypeError` condition was unclear. As far as I
know this condition can never be false (`e` is an instance of an exception,
not an exception class).

I think this is still in line with the original intent of this code, which
was to make common coercions like `float` work with nullable fields out
of the box: pyeve#269
nikhaldi pushed a commit to nikhaldi/cerberus that referenced this issue May 6, 2019
Only ignore exceptions if a value for a nullable field is not null.
Previously all exceptions during custom coerction were ignored with nullable
fields. The developer and/or user most likely wants to know about
exceptions that happen during coercion - this leads to hard to debug
problems otherwise.

The purpose of the `e is not TypeError` condition was unclear. As far as I
know this condition can never be false (`e` is an instance of an exception,
not an exception class).

I think this is still in line with the original intent of this code, which
was to make common coercions like `float` work with nullable fields out
of the box: pyeve#269
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants