id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
20999	Cannot specify form_class that isn't subclass of TypedChoiceField for field with choices	Carl Meyer	nobody	"In `Field.formfield()`, if `self.choices` is set, Django overrides any supplied `form_class` with `TypedChoiceField` unless the given `form_class` is a subclass of `TypedChoiceField`. This is unnecessarily restrictive (as explicit type checks usually are), and is particularly problematic when working with a field that takes multiple values (such as a Postgres array field), where `TypedMultipleChoiceField` would be the appropriate form field class, because `TypedMultipleChoiceField` is not a subclass of `TypedChoiceField`.

Prior to the fix for #18162, Django was even more restrictive; a custom `form_class` was not respected at all when choices were set.

I think the wrong fix for #18162 was chosen. The original patch provided by rafallo there would have respected a new keyword argument to `formfield()`, `form_class_for_choices`. This provides full flexibility, and is conceptually more correct; since a totally different form field is generally needed for the same db field when there are choices, a separate keyword argument to control this form field is appropriate. I propose that we switch to rafallo's fix (though I prefer the slightly shorter name `choices_form_class`).

Unfortunately since the subclass check was committed and released in the 1.6 betas, we probably still have to maintain compatibility with people passing a subclass of `TypedChoiceField` as `form_class` and expecting it to be used when choices are set."	New feature	closed	Forms	dev	Normal	fixed			Ready for checkin	1	0	0	0	0	0