It's a bit unexpected that disabled_choices isa frozenset in the patch when choices is a list. Since disabled_choices is a subset of choices, it should be whatever choices is, and it's somewhat common to change choices after init it should be expected that disabled_choices also change.
On Friday, June 10, 2011 10:10:29 PM UTC+8, Jody McIntyre wrote: > > Can a core developer please advise on the preferred design here? > > The main ideas are: > > 1. Add a 'disabled_choices' attribute to the widget that takes an > iterable of choices to disable. I've attached a WIP patch to ticket > 16149 following this approach. Optionally this could be passed to the > widget by forms.ChoiceField similarly to the way choices is handled > now. > > A concern was raised in the ticket (16149) that this is too specific, > and we should also be able to pass arbitrary HTML attributes like > class, style, and id. I don't understand the use case for passing > these things to an <option>, so I don't think this is worthwhile, but > it's something to consider. > > 2. Extend the "choices" data structure, as suggested by Calvin > Spealman in the discussion. > > Thanks, > Jody > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
