Dynamically setting choices for a ChoiceField is inconsistent

[jason@…]

To get your list of choices to show up in a ChoiceField before a form is submitted, you must set field.widget.choices = your_iterable. Setting field.choices has no effect. To get the field to validate you must set field.choices = your_iterable, not field.widget.choices. This is inconsistent and confusing. It seems to me that setting field.choices should be the correct thing to do for both.

[Jason Prado <jason@…>]

Adds a set_choices method to ChoiceField/MultiChoiceField

[Jason Prado <jason@…>]

The attached patch adds a set_choices method to ChoiceField/MultiChoiceField classes that sets the choices field in the Field and then tells the Widget about it.

[Adrian Holovaty]

The current way it's handled is intentional -- a Field doesn't know anything about the internals of its Widget. The Widget.choices completely defines display, whereas the Field.choices completely defines valid options. I agree that this can be confusing, but something rubs me the wrong way about having a Field manipulate the internals of its Widget.

I'm putting [design-q] in the ticket summary to designate "a design decision needs to be made here."

[Adrian Holovaty]

OK, I made the design decision. :-)

In [4378], I changed ChoiceField.__init__() so that a widget uses the choices from its ChoiceField regardless of whether the widget has its own choices.

The next step, to fix this particular ticket, is to accomodate for users who set choices on the field after the fact. Rather than use the behavior in this patch (set_choices() methods), I'd rather we used properties, to be more Pythonic and transparent.

[Adrian Holovaty]

I'll take care of the patch, BTW.

[Adrian Holovaty]

(In [4379]) Fixed #3196 -- Fixed inconsistency in setting choices on ChoiceFields dynamically