The approach you suggested was suggested in the thread of ticket you
Brian Rosner: "I am a +1 on a configuration parameter since the alternative
by subclassing is a bit too involved for something fairly trivial."
Why was it rejected? What new arguments are you bringing to the table that
weren't considered before?
You say that subclassing is a burden, but I'd argue that even redefining
the field on the model form isn't DRY, at which point what about making the
customization in the form's __init__()?
self.fields['field_name'].label_from_instance = lambda obj: 'new label'
I think the barrier to violate the Zen of Python ("There should be one--
and preferably only one --obvious way to do it.") is a bit high here, so
perhaps you could elaborate on how this is causing maintenance problems?
On Tuesday, September 20, 2016 at 9:52:55 PM UTC-4, Lawrence Vanderpool
> Older related ticket: https://code.djangoproject.com/ticket/4620
> My rough draft of proposed changes:
> The problem of setting the label for ModelChoiceField is one that comes up
> on IRC every once in a while. It's a common enough problem that I think the
> documentation-recommended solution of subclassing ModelChoiceField and
> setting label_from_instance (
> ) is overkill, and probably a maintenance problem.
> ModelChoiceField already implements an optional callable in the
> `get_limit_choices_to` function. This change would implement a similar API
> to allow a callable to be passed in to the constructor rather than having
> to do the subclassing dance.
> It'd still be backwards compatible, but the documentation should be
> changed to reflect the "easier" solution of passing in the callable.
> The old ticket was labelled wontfix, but I think we should take a look
> again. I'd love for this to be my first contribution to Django! Thanks for
> any feedback. And if I forgot something or broke a rule for the ML, I
> apologize in advance @.@
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.