Allowing single values instead of tuples for choices in ChoiceField
gruszczy
I have created a ticket here: http://code.djangoproject.com/ticket/11644,
but it was marked wontfix and told to ask here about this change.
The issue is that I consider convenient being able to pass a list of
either tuples or single objects for choices list in forms ChoiceField.
The engine would itself detect non-tuple values and turn them into two-
tuples. There are some good points in the comment (like lacking
documentation/tickets, which I would gladly provide), but first I
would like to ask, if such a feature would be acceptable, just like
the advice in the comment suggested.
Best regards
Jacob Kaplan-Moss
> The issue is that I consider convenient being able to pass a list of
> either tuples or single objects for choices list in forms ChoiceField.
> The engine would itself detect non-tuple values and turn them into two-
> tuples. There are some good points in the comment (like lacking
> documentation/tickets, which I would gladly provide), but first I
> would like to ask, if such a feature would be acceptable, just like
> the advice in the comment suggested.
Frankly I don't see the point.
What does::
f = CharField(choices=LIST)
have over::
f = CharField(choices=zip(LIST, LIST))
?
Jacob
Malcolm Tredinnick
Russell's comments about it being an edge-case and particularly broken
with respect to localization are key points here. The proposal cannot
stand on its own without addressing those.
In any case, I'm with Jacob and Russell on being a strong -1 here. It's
a dozen extra characters of very standard Python if you want to do this
in your own code. Not worth adding to Django's core, along with all the
accompanying documentation and regression testing and maintenance.
Regards,
Malcolm
Filip Gruszczyński
> a dozen extra characters of very standard Python if you want to do this
> in your own code. Not worth adding to Django's core, along with all the
> accompanying documentation and regression testing and maintenance.
OK, thanks for the reply and comment. I'll stick to zips then and look
for some other small thing I could try to patch.
Best regards
--
Filip Gruszczyński
andybak
f = CharField(choices=zip
(some_complex_expression_that_generates_a_list,
some_complex_expression_that_generates_a_list))
You don't really want to assign the expression to a variable within
your model and if you put it elsewhere then it hurts readability
somewhat.
I doubt that this is sufficient to sway anyone but I thought I'd throw
in my +0.5 ;-)
Daniel Roseman
f = CharField(choices = [(x, x) for x in some_complex_expression])
--
DR.
Malcolm Tredinnick
> It does get slightly uglier when you have cases such as:
> f = CharField(choices=zip
> (some_complex_expression_that_generates_a_list,
> some_complex_expression_that_generates_a_list))
>
> You don't really want to assign the expression to a variable within
> your model and if you put it elsewhere then it hurts readability
> somewhat.
By "hurts" you mean "improves". Having long lines of nested computations
is not particularly nice style for Python readability (it works in other
languages where nested calls are commonplace, but it's not particularly
normal in Python). Assign to a constant and you'll be able to tell from
looking at the code that the data comes from a constant defined
elsewhere in this file (or which file it is defined in if it refers to
<module_name>.<constant_name>).
Also, the elephant in the room here is that this whole proposal is a
somewhat bad programming pattern. The choice value should be unchanging.
The choice display string can and often does change. If you use the
automatically use the same value for both and don't write it out that
way, you cannot change the values once you include them.
Regards,
Malcolm