Opened 7 years ago

Closed 23 months ago

#13181 closed New feature (fixed)

ChoiceField.choices need to accept callable, not only list or tuple

Reported by: mariarchi Owned by: Peter Inglesby
Component: Forms Version: master
Severity: Normal Keywords: ChoiceField, choices
Cc: admin@…, t.zander@…, someuniquename@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

see http://groups.google.com/group/django-developers/browse_thread/thread/3d98f84430bda806

The subject pretty much describes all of it. If 'initial' can be a
callable, why 'choices' can't? Writing custom function is way more
convenient then altering init method of the model.

Attachments (5)

patch.diff (1.6 KB) - added by mariarchi 7 years ago.
as_actual_callable.diff (2.6 KB) - added by Klaas van Schelven 4 years ago.
with_callable_choice_iterator.diff (2.7 KB) - added by Klaas van Schelven 4 years ago.
full_version.diff (5.3 KB) - added by Klaas van Schelven 4 years ago.
with_field_as_param.diff (3.0 KB) - added by Klaas van Schelven 4 years ago.

Download all attachments as: .zip

Change History (35)

comment:1 Changed 7 years ago by mariarchi

Needs documentation: unset
Needs tests: set
Patch needs improvement: unset

I would've written up tests, but I didn't really get how to add methods to regression tests - all functions have numbers - do you have to rename everything below inserted one?

comment:2 Changed 7 years ago by Alex Gaynor

No, the numbers on the test objects are fairly arbitrary, feel free to name you TestCase methods more semantic.

comment:3 Changed 7 years ago by mrts

It's still important to check if the result can be converted to a list:

if callable(value):
    value = value()
value = list(value)

Changed 7 years ago by mariarchi

Attachment: patch.diff added

comment:4 Changed 7 years ago by mariarchi

@mrts: thx, updated the patch

comment:5 Changed 7 years ago by mariarchi

Needs tests: unset

...and tests

comment:6 Changed 7 years ago by Russell Keith-Magee

Triage Stage: UnreviewedAccepted

comment:7 Changed 5 years ago by Luke Plant

Type: New feature

comment:8 Changed 5 years ago by Luke Plant

Severity: Normal

comment:9 Changed 5 years ago by Julien Phalip

Needs documentation: set

comment:10 Changed 5 years ago by Julien Phalip

Easy pickings: unset

#15950 is a dupe and has a patch with a different approach.

comment:11 Changed 5 years ago by Aymeric Augustin

UI/UX: unset

Change UI/UX from NULL to False.

comment:12 in reply to:  11 Changed 4 years ago by t.zander@…

Cc: t.zander@… added

I'm interested in this, what's the status of it?

comment:13 Changed 4 years ago by Klaas van Schelven

I'll probably look into it in the upcoming sprint in Utrecht (Feb 23rd 2013).
Notes if anyone's picking it up before that:

The comment made by mrts (https://code.djangoproject.com/ticket/13181#comment:3) is (as far as I understand it) not a good idea. As far as I understand it he/she is talking about evaluating the callable at field-definition time as well as when the form is actually initialized using form = MyForm().

But this is exactly one of the problems I'm dealing with: on form definition time the callable that is bound to choices may not have a meaningful result. It may be erratic (because it fetches results over the internet or depends on a database that is sometimes offline). If you have such a callable it will crash the whole application in the current situation and the situation proposed by mtrs.

My 2 cents.

comment:14 Changed 4 years ago by Klaas van Schelven

Owner: changed from nobody to Klaas van Schelven
Status: newassigned

Changed 4 years ago by Klaas van Schelven

Attachment: as_actual_callable.diff added

comment:15 Changed 4 years ago by Klaas van Schelven

Attached (as_actual_callable.diff) is a super-ugly solution to what I consider the "real problem". Please see this as a starting point for further discussion.

The earlier patch basically evaluated the callable on-field-definition, i.e. once. The whole purpose of using a callable is to lazily evaluate so that was not an acceptible solution.

I noticed ModelChoiceField had this problem solved (as opposed to the regular ChoiceField), i.e. for each instance of a form the field's choices are freshly looked up in the queryset. In that case, they've made it work by patching __deepcopy__ (which is called when a form is instantiated) to change the widget's choices every time.

See this solution here:
https://github.com/django/django/blob/6bbf4e57c8b250d09a70d3d840531a42147705e9/django/forms/models.py#L954

My solution does something similar: on deepcopy the actual evaluation is done. Note also the fact that the widget's choices have to be manually set to an actual value, which happens in _set_choices()

Note that I use a different attribute to store the callable version of the choices. I hardly dare to call this elegant, but the amount of places there's dependencies on the fact that choices is an iterator is rather huge. Putting the callable version of choices in a different location makes sure we can dance around those issues.

comment:16 Changed 4 years ago by Klaas van Schelven

Owner: Klaas van Schelven deleted
Status: assignednew

comment:17 Changed 4 years ago by expleo

I managed to get it working this way: https://github.com/django/django/pull/770/files

Changed 4 years ago by Klaas van Schelven

comment:18 Changed 4 years ago by Klaas van Schelven

This approach (with_callable_choice_iterator.diff) is a prettier way to wrap the callable. The attached diff is the minimal way to get this issue fixed; I'll further look in to ways that combine it with:

  • Refactoring CallableChoiceIterator and ModelChoiceIterator to be of a common base class
  • We may want to consider passing field to the callable so that the callable has a bit more context. I'll play a bit with it.

Changed 4 years ago by Klaas van Schelven

Attachment: full_version.diff added

Changed 4 years ago by Klaas van Schelven

Attachment: with_field_as_param.diff added

comment:19 Changed 4 years ago by Klaas van Schelven

Comments on the recent patches:

  • I'm not a fan of the "refactoring" using the delegate presented in "full_version". The commonalities are simply not worth the refactoring.
  • I do like the version where the field is sent as a param; but whether that's actually useful is DDN.

comment:20 Changed 4 years ago by expleo

Updated pull request with with_field_as_param.diff:
https://github.com/django/django/pull/770/files

comment:21 Changed 4 years ago by expleo

Triage Stage: AcceptedDesign decision needed

comment:22 Changed 4 years ago by Florian Apolloner

Triage Stage: Design decision neededAccepted

Moving back to "Accepted" since the ticket per se is accepted and we are dropping DDN.

comment:23 Changed 3 years ago by Evstifeev Roman

Cc: someuniquename@… added

comment:24 Changed 2 years ago by Peter Inglesby

Owner: set to Peter Inglesby
Status: newassigned

comment:25 Changed 2 years ago by Peter Inglesby

https://github.com/django/django/pull/770 was stale so I have created a new PR: https://github.com/django/django/pull/3427, which now includes documentation changes.

comment:26 Changed 2 years ago by Peter Inglesby

Needs documentation: unset

comment:27 Changed 2 years ago by Tim Graham

Patch needs improvement: set
Version: 1.2-betamaster

I left comments for improvement on the PR. Please uncheck "Patch needs improvement" when you update it, thanks.

comment:28 Changed 2 years ago by Peter Inglesby

Thanks Tim for the review.

I think there's one outstanding issue with the ticket, relating to the change in ChoiceField.__deepcopy__. I've left my thoughts on the PR.

comment:29 Changed 23 months ago by Peter Inglesby

Patch needs improvement: unset

comment:30 Changed 23 months ago by Tim Graham <timograham@…>

Resolution: fixed
Status: assignedclosed

In 74e1980cf96eb45079bef464fabdcbe0a6db2423:

Fixed #13181 -- Added support for callable choices to forms.ChoiceField

Thanks vanschelven and expleo for the initial patch.

Note: See TracTickets for help on using tickets.
Back to Top