[Django] #35126: forms.NullBooleanField's validation logic is surprising
Django
----------------------------------------+------------------------
Reporter: Jeremy Lainé | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 5.0
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
----------------------------------------+------------------------
Reading NullBooleanField's code lead me to believe that it would clean
`"1"` to `True`, and `"0"` to `False`", just like `BooleanField` does:
A simple field-level test works:
{{{
>>> from django import forms
>>> field = forms.NullBooleanField()
>>> field.clean("1")
True
>>> field.clean("0")
False
}}}
But using this in an actual form fails, not the difference between the
`BooleanField` and `NullBooleanField`:
{{{
>>> class DemoForm(forms.Form):
... field_a = forms.BooleanField()
... field_b = forms.NullBooleanField()
...
>>> form = DemoForm({"field_a": "1", "field_b": "1"})
>>> form.is_valid()
>>> form.cleaned_data
{'field_a': True, 'field_b': None}
}}}
The problem is that by default `NullBooleanField` uses a
`NullBooleanSelect` which mangles the submitted data for some obscure
backwards-compatibility reason:
--
Ticket URL: <https://code.djangoproject.com/ticket/35126>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Jeremy Lainé | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 5.0
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Description changed by Jeremy Lainé:
Old description:
> Reading NullBooleanField's code lead me to believe that it would clean
> `"1"` to `True`, and `"0"` to `False`", just like `BooleanField` does:
>
> https://github.com/django/django/blob/10c7c7320baf1c655fcb91202169d77725c9c4bd/django/forms/fields.py#L850
>
> A simple field-level test works:
>
> {{{
> >>> from django import forms
> >>> field = forms.NullBooleanField()
> >>> field.clean("1")
> True
> >>> field.clean("0")
> False
> }}}
>
> But using this in an actual form fails, not the difference between the
> `BooleanField` and `NullBooleanField`:
>
> {{{
> >>> class DemoForm(forms.Form):
> ... field_a = forms.BooleanField()
> ... field_b = forms.NullBooleanField()
> ...
> >>> form = DemoForm({"field_a": "1", "field_b": "1"})
> >>> form.is_valid()
> >>> form.cleaned_data
> {'field_a': True, 'field_b': None}
> }}}
>
> The problem is that by default `NullBooleanField` uses a
> `NullBooleanSelect` which mangles the submitted data for some obscure
> backwards-compatibility reason:
>
> https://github.com/django/django/blob/10c7c7320baf1c655fcb91202169d77725c9c4bd/django/forms/widgets.py#L816
New description:
Reading NullBooleanField's code lead me to believe that it would clean
`"1"` to `True`, and `"0"` to `False`", just like `BooleanField` does:
A simple field-level test works:
{{{
>>> from django import forms
>>> field = forms.NullBooleanField()
>>> field.clean("1")
True
>>> field.clean("0")
False
}}}
But using this in an actual form fails, note the difference between the
`BooleanField` and `NullBooleanField`:
{{{
>>> class DemoForm(forms.Form):
... field_a = forms.BooleanField()
... field_b = forms.NullBooleanField()
...
>>> form = DemoForm({"field_a": "1", "field_b": "1"})
>>> form.is_valid()
>>> form.cleaned_data
{'field_a': True, 'field_b': None}
}}}
The problem is that by default `NullBooleanField` uses a
`NullBooleanSelect` which mangles the submitted data for some obscure
backwards-compatibility reason:
--
--
Ticket URL: <https://code.djangoproject.com/ticket/35126#comment:1>
Django
------------------------------+--------------------------------------
Type: Bug | Status: assigned
Component: Forms | Version: 5.0
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+--------------------------------------
* owner: nobody => sarangkkl
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/35126#comment:2>
Django
------------------------------+--------------------------------------
Type: Bug | Status: closed
Component: Forms | Version: 5.0
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+--------------------------------------
* status: assigned => closed
* resolution: => invalid
Comment:
It's clearly
[https://docs.djangoproject.com/en/5.0/ref/forms/fields/#nullbooleanfield
documented] with what kind of widgets (and set of choices) you can use
`NullBooleanField()`:
> ''"NullBooleanField may be used with widgets such as Select or
RadioSelect by providing the widget choices:"''
I don't see anything to fix here.
--
Ticket URL: <https://code.djangoproject.com/ticket/35126#comment:3>
Django
------------------------------+--------------------------------------
Reporter: Jeremy Lainé | Owner: Gaurav sah
Type: Bug | Status: closed
Component: Forms | Version: 5.0
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+--------------------------------------
Comment (by Jeremy Lainé):
I'm a bit surprised by this answer, it seems somewhat besides the point.
I'm not arguing you cannot use other widgets, I'm saying the default
widget alters the validation behaviour in an unexpected fashion.
I would expect NullBooleanField to behave exactly like BooleanField for
values which normalise to True / False, and validate other values to None.
This is exactly what NullBooleanField.to_python expresses too. However
this is not the case out of the box: "0" and "1" get validated to None
because of what looks like an oversight in NullBooleanWidget.
This was especially surprising in my use case where I don't even use
widgets at all, and purely use forms to validate data.
--
Ticket URL: <https://code.djangoproject.com/ticket/35126#comment:4>
Django
------------------------------+--------------------------------------
Reporter: Jeremy Lainé | Owner: Gaurav sah
Type: Bug | Status: closed
Component: Forms | Version: 5.0
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+--------------------------------------
Comment (by David Sanders):
Hi Jeremy,
If you'd like, it'd be better to start a discussion either on Discord or
on the Django forum as only a limited number of people will see your
points raised. Mariusz is quite busy and may be unlikely to respond :)
Additionally someone may be able to explain the reasons why
NullBooleanSelect diverges in that way.
--
Ticket URL: <https://code.djangoproject.com/ticket/35126#comment:5>
Django
------------------------------+--------------------------------------
Reporter: Jeremy Lainé | Owner: Gaurav sah
Type: Bug | Status: closed
Component: Forms | Version: 5.0
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+--------------------------------------
Comment (by Tim Graham):
It seems like a useful improvement, if feasible. Jeremy, it would have
been most helpful if you did some investigation regarding the backwards
compatibility comment rather than simply describing it as "some obscure
reason." Using `git blame` leads to
35a08b8541c856a51b2ab718e0a2fe060debfa2a (#17210). If you're able to
provide a proof of concept solution, feel free to ping me (@timgraham) on
a draft GitHub pull request.
--
Ticket URL: <https://code.djangoproject.com/ticket/35126#comment:6>