Previously, get_FIELD_display(), for a blank or unknown value of
FIELD, return the value unchanged, e.g. say None or an empty string.
After the change, it returns the automatically inserted blank choice
(-------). This is due to it now using field.flatchoices, which is
dynamically generated through the get_choices() method, whereas it
previously just used field.choices, which contains the unmodified
tuple the field receives through __init__.
This may also be an unwanted discrepancy between the two attributes.
Was it a conscious change? I think I did sort of prefer the old
behaviour. I'm using get_field_display in a generic scenario that
makes it hard to check the original value.
> Previously, get_FIELD_display(), for a blank or unknown value of > FIELD, return the value unchanged, e.g. say None or an empty string.
> After the change, it returns the automatically inserted blank choice > (-------). This is due to it now using field.flatchoices, which is > dynamically generated through the get_choices() method, whereas it > previously just used field.choices, which contains the unmodified > tuple the field receives through __init__. > This may also be an unwanted discrepancy between the two attributes. > Was it a conscious change? I think I did sort of prefer the old > behaviour. I'm using get_field_display in a generic scenario that > makes it hard to check the original value.
There certainly wasn't a conscious decision to change anything. However, I'm having a little difficulty reproducing your problem. Here's a quick test case:
class Whiz(models.Model): CHOICES = ( (1,'First'), (0,'Other'), ) c = models.IntegerField(choices=CHOICES, null=True)
__test__ = {'API_TESTS':"""
>>> w = Whiz(c=1) >>> w.save() >>> w.get_c_display()
This should have been more obvious to me in the first place. The
problem only exists for an empty string value (the choices in my
particular case hat string keys, and the field was not nullable).
Tries this case:
>>> w = Whiz(c='')
>>> w.save()
>>> w.get_c_display()
u''
Expected:
u''
Got:
u'---------'
That particular case behaved differently before the change, for the
reason mentioned, i.e.:
On Tue, 2008-07-22 at 04:21 -0700, Michael Elsdörfer wrote: > Previously, get_FIELD_display(), for a blank or unknown value of > FIELD, return the value unchanged, e.g. say None or an empty string.
> After the change, it returns the automatically inserted blank choice > (-------). This is due to it now using field.flatchoices, which is > dynamically generated through the get_choices() method, whereas it > previously just used field.choices, which contains the unmodified > tuple the field receives through __init__. > This may also be an unwanted discrepancy between the two attributes.
> Was it a conscious change? I think I did sort of prefer the old > behaviour. I'm using get_field_display in a generic scenario that > makes it hard to check the original value.
This sounds like an unintended side-effect and probably worth opening a ticket for. That change was meant to add a new feature, not change existing code.
> This sounds like an unintended side-effect and probably worth opening a
> ticket for. That change was meant to add a new feature, not change
> existing code.
