Fix boolean validation when string is passed as value

[MattBlack85]

the following example:

class BoolSerializer(serializers.Serializer):
    bool_field = serializer.BooleanField()

does behave in such case:

>>> s = BoolSerializer(data={'bool_field': 'somestring'})
>>> s.is_valid()
>>> True

[xordoquy]

I'm not convinced it's a good idea to raise a ValidationError within the from_native. Shouldn't it be in the validate ?

[tomchristie]

Incorrect behaviour if value is True, False, 1 and 0.

[tomchristie]

Closing this off. On my checklist for #1800.

[MattBlack85]

Any remote chance to have it in 2.x?

[tomchristie]

Nope. Cracking on with 3.0, rather focus on that. The behaviour as it currently is reasonable enough in any case. If you want alternate behavior, use a custom field class.

[AeroNotix]

@tomchristie Regarding this being "reasonable" -- part of the huge amount of hate against PHP is the fact that it has automatic conversions such as this. Do you want to make DRF work like PHP?

[xordoquy]

@AeroNotix Please avoid such negative statements.
DRF has limited resources and putting more things into 2.x will simply delay even more the work for 3.x which will deal with this issue and make the code in this PR obsolete.

[AeroNotix]

@xordoquy I don't see the negativity. I'm genuinely surprised at the behaviour introduced in the 3.0 branch. The allowed values don't even make sense for a boolean field for the serialized types available.

    TRUE_VALUES = set(('t', 'T', 'true', 'True', 'TRUE', '1', 1, True))
    FALSE_VALUES = set(('f', 'F', 'false', 'False', 'FALSE', '0', 0, 0.0, False))

Which formats allow '0' or 0 or 0.0 to represent false? DRF supports JSON (which does not support anything other than true/false), YAML (which supports a couple of things like NO and 'N', yet you do not support them here).

Ideally the allowed values would take into account the format being parsed and validate based on those values.

[xordoquy]

@AeroNotix the "reasonable" part applies to the current branch.
As for 3.x I do think you'll be able to override the default fields to provide a stricter policy.