On Sun, 2009-08-09 at 00:41 -0700, andybak wrote: > 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
