Changes between Initial Version and Version 1 of Ticket #16663, comment 2


Ignore:
Timestamp:
08/21/2011 03:47:40 PM (4 years ago)
Author:
aaugustin
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #16663, comment 2

    initial v1  
    1616I began working on a patch (first patch attached)... and failed horribly.
    1717
    18 In fact, if we want to handle properly the case when an empty list is passed in the `choices` argument, we mustn't set `self.choices = []` when the argument isn't passed.  Otherwise we can no longer tell if (a) no choices were given or (b) a empty list was given, that will be populated later. This becomes ugly very quickly because Django uses `if <field>.choices` in many places. I'm afraid a lot of third-party code (like custom fields) also uses this idiom.
     18In fact, if we want to handle properly the case when an empty list is passed in the `choices` argument, we mustn't set `self._choices = []` when the `choices` argument isn't passed.  Otherwise we can no longer tell if (a) no choices were given or (b) a empty list was given, that will be populated later. This becomes ugly very quickly because Django uses `if <field>.choices` in many places. I'm afraid a lot of third-party code (like custom fields) also uses this idiom.
    1919
    20 In particular, Django only creates `get_FOO_display` when `<field>.choices` evaluates to `True` when the field is initialized, which is why the test in my patch fail.
     20In particular, Django only creates `get_FOO_display` when `<field>.choices` evaluates to `True` when the field is initialized, which is why the test in my patch fails.
    2121
    2222----
Back to Top