Code

Opened 5 years ago

Closed 5 years ago

#11644 closed (wontfix)

Allowing single values instead of tuples for choices in ChoiceField

Reported by: gruszczy Owned by: nobody
Component: Uncategorized Version: 1.1
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

At the moment, when I want set choices for a ChoiceField, I have to put a list of tuples. In some situations this is inconvenient, e.g. when I have list of values that I just want to use. For example I have to do it like this:

   choices = ['A', 'B', 'C']
   choice_field = ChoiceField(choices=zip(choices, choices))

It would be eaiser if I could just do it like this:

   choice_field = ChoiceField(choices=['A', 'B', 'C'])

And even more, like this:

   choice_field = ChoiceField(choices=['A', 'B', ('C', 'c')])

And all of this would create choices lists with tuples, e.g. the last one would look like this: [('A', 'A'), ('B', 'B'), ('C', 'c')].
I am adding a patch, that does it.

Attachments (1)

fields.py.diff (729 bytes) - added by gruszczy 5 years ago.

Download all attachments as: .zip

Change History (2)

Changed 5 years ago by gruszczy

comment:1 Changed 5 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to wontfix
  • Status changed from new to closed

On a purely procedural note - Nobody in the core or triage team is going to take a patch seriously unless it has tests. If it touches public-facing API like this modification will, at least a draft of documentation is a requirement too. Also - code needs to be Python 2.3 compatible. This patch uses the inline-if notation that wasn't available until Python 2.5.

On a feature note - I'm afraid I don't see the benefit here. zip isn't that hard to use in your particular use case. Explicit is better than implicit. On top of that, the set of cases where you can actually use the same value for database storage as for public display would be fairly small, in my experience. If you're doing any sort of internationalization, for example, this approach won't serve any use at all.

I'm marking this wontfix. If you are particularly enthused by this idea, feel free to start a discussion on django-developers and make your case.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.