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

Booleans are accepted for type integer #144

Closed
mbalser opened this Issue Sep 10, 2015 · 9 comments

Comments

Projects
None yet
3 participants
@mbalser
Copy link

mbalser commented Sep 10, 2015

Internally cerberus 0.10 does the following:

>>> isinstance(1, (int,))
True
>>> isinstance(True, (int,))
True
>>> isinstance(0, (int,))
True
>>> isinstance(False, (int,))
True

Of course I could map True and False to integers using Value Coercion, but this seems awkward and feels it is not the correct thing to do when using a type check for integers and not explicitly for booleans.

@funkyfuture

This comment has been minimized.

Copy link
Member

funkyfuture commented Sep 10, 2015

what you show is Python's intended design.

can you elaborate your use-case?

@funkyfuture

This comment has been minimized.

Copy link
Member

funkyfuture commented Sep 10, 2015

btw, gh's markdown renders code between three backticks (not very accessible on qwertz-layouts).

@mbalser

This comment has been minimized.

Copy link

mbalser commented Sep 10, 2015

The usecase is a customer facing api where I use cerberus for input validation. I want to clearly distinguish between truth values (true/false) and integers (1....1024).

Of course you are right about the python design choice, but I would rather not like to expose python internal "way-of-doing-things" to a backend neutral api. So my suggestion is to keep the current way of handling bool/int for backwards compatibility and provide something like a "strict" parameter which enforces that int has to be a number and not a boolean.

@mbalser

This comment has been minimized.

Copy link

mbalser commented Sep 10, 2015

I think boolean is already strict - I guess only integer would require a "stricter" version - something like "integer_strict" or such.

The change itself should be quite trivial:

def _validate_type_integer_strict(self, field, value):
    if not isinstance(value, _int_types) or isinstance(value, bool):
        self._error(field, errors.ERROR_BAD_TYPE.format("integer"))
@funkyfuture

This comment has been minimized.

Copy link
Member

funkyfuture commented Sep 11, 2015

would the more generic number be suitable?

@mbalser

This comment has been minimized.

Copy link

mbalser commented Sep 11, 2015

Although "number" is very generic in regards to int/float, but I think it would be a good fit.

@funkyfuture

This comment has been minimized.

Copy link
Member

funkyfuture commented Sep 11, 2015

yep, it isn't bound to a builtin-type anyway.

and numbers are infinite while 'true' / 'false' are (questionable,) very finite / determined concepts. ;-)

funkyfuture added a commit to funkyfuture/cerberus that referenced this issue Jan 31, 2016

nicolaiarocci added a commit that referenced this issue Feb 1, 2016

@arnauorriols

This comment has been minimized.

Copy link

arnauorriols commented Jul 20, 2016

I apologize for commenting on an already closed issue.

@mbalser #144 (comment) depicts precisely my opinion on this, and for me "number" is not suitable. Can you elaborate on the justification to expose Python's implementation details to a high-level tool like is Cerberus?

(I sincerely hope 3 == 2 + True was not really the Python's intended design, but rather an implementation trade-off)

@funkyfuture funkyfuture referenced this issue Jul 26, 2016

Closed

Having a `ValidatorBase` in version 1? #249

1 of 1 task complete
@funkyfuture

This comment has been minimized.

Copy link
Member

funkyfuture commented Jul 26, 2016

well, the types are not all high-level i think (e.g. binary, datetime).

meanwhile a release candidate has taken form; it would be possible to change that and break bw-compatibility. i think it's okay to be more strict as {'type': 'integer'} -> {'type': ('bool', 'integer')} is an easy change.

(I sincerely hope 3 == 2 + True was not really the Python's intended design, but rather an implementation trade-off)

if that is the case, it must be changed as other interpreters may implement it differently. someone must lookup the specs.

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