CheckboxInput don't work with 0 and 1 value (considerd as Booleans)

[alexis_m]

Hello,

I think I've discovered an unwanted behavior in the "render" method of the CheckboxInput class, or maybe I don't understand how it's designed to be used.

When using the render() method, with a value of 0 or 1, the verification process, made by the following code:

if value not in ('', True, False, None):

prevents the "value" attribute to be shown.

It's mainly because 1 and 0 are considéred equals to True and False.

Here is my proposition to solve this:

if (value not in ('', None)) and str(value) not in ('False', 'True'):

Another option can be to use force_unicode from from django.utils.encoding on incoming values.

Thanks

[alexis_m]

diff for the patch proposition

[Benoît Bryon]

Additional information about the report.

There are two questions:

• about a use case : "how to have a MultipleChoiceField that normalizes to something different than a list of unicode values ?"
• about a code design : "why is this behaviour silent ?"

About the use case

A TypedChoiceField exists, but there is no MultipleTypedChoiceField available.
Subclassing MultipleChoiceField to add TypedChoiceField "coerce" functionality can solve the use case.
Another ticket may be opened to propose such an enhancement.

About "silent" behaviour

It seems that the CheckboxInput widget is designed to handle string/unicode values, such as choices provided by MultipleChoiceField.

If this is a wanted behaviour :

• it should be written in the documentation at ​http://docs.djangoproject.com/en/dev/ref/forms/widgets/#django.forms.CheckboxInput
• AND/OR an exception should be raised, in order to prevent developer from bad usage
• OR there is a reason I do not know, and it makes the behaviour helpful (but still not documented, even in code)

If this an unwanted behaviour :

• loot at the submitted patch

[Russell Keith-Magee]

Marking invalid because I'm completely confused as to the problem here.

• The original report doesn't give the use case that causes this to be an issue
• The patch isn't generated against the root of the source tree
• There's no test case to validate the new behavior (or explain the problem)
• I can't see the connection between the problem report and the first comment.

Feel free to reopen if you can provide more details.