Opened 15 years ago
Closed 15 years ago
#11644 closed (wontfix)
Allowing single values instead of tuples for choices in ChoiceField
Reported by: | Filip Gruszczyński | 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: | no | UI/UX: | no |
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)
Change History (2)
by , 15 years ago
Attachment: | fields.py.diff added |
---|
comment:1 by , 15 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Note:
See TracTickets
for help on using tickets.
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.