+1 to everything that Alex Hill said. It seems super inconsistent to me
that ``to_field_name`` is available as an argument to the constructor, but
we have to subclass to override ``label_from_instance``.
It would be one thing if there were some complex logic going on there, but
the vanilla ``l
My reasoning is basically Alex Hill's. Subclassing for one bit of
functionality and using a callable for another is an inconsistent API, and
of the two, the callable is preferrable from a maintainability and
readability standpoint (for all the reasons he's already stated so well!)
On Tuesday, S
I like this!
Having read through the existing ticket and discussion, really the only
reason given is a cultural one: that subclassing is the way this kind of
behaviour "should" be achieved. I disagree – IME, APIs that encourage
parametrising small chunks of behaviour are succinct and flexible, and
The approach you suggested was suggested in the thread of ticket you
mentioned:
https://groups.google.com/d/topic/django-developers/7DDEX73zVrI/discussion
Brian Rosner: "I am a +1 on a configuration parameter since the alternative
by subclassing is a bit too involved for something fairly trivia
Older related ticket: https://code.djangoproject.com/ticket/4620
My rough draft of proposed
changes:
https://gist.github.com/mekhami/24af779f4f491d3c66e6fd607c2121aa/revisions
The problem of setting the label for ModelChoiceField is one that comes up
on IRC every once in a while. It's a common
