Backwards incompatible change by #4412 / r7977 (flatchoices)

1 view
Skip to first unread message

Michael Elsdörfer

unread,
Jul 22, 2008, 7:21:53 AM7/22/08
to Django developers
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.

Michael

Russell Keith-Magee

unread,
Jul 22, 2008, 8:17:48 AM7/22/08
to django-d...@googlegroups.com

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()
u'First'

>>> w.c = 0
>>> w.save()
>>> w.get_c_display()
u'Other'

# Test an invalid data value
>>> w.c = 9
>>> w.save()
>>> w.get_c_display()
9

# Test a blank data value
>>> w.c = None
>>> w.save()
>>> print w.get_c_display()
None

"""}

This test case works fine for me both pre-7977 and post-7977. Have I
misunderstood your use case here?

Yours,
Russ Magee %-)

Michael Elsdörfer

unread,
Jul 22, 2008, 9:05:48 AM7/22/08
to Django developers
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.:

>>> Whiz._meta.get_field('c').choices
((1, 'First'), (0, 'Other'))

>>> Whiz._meta.get_field('c').flatchoices
[('', '---------'), (1, 'First'), (0, 'Other')]

Michael

Malcolm Tredinnick

unread,
Jul 22, 2008, 1:32:35 PM7/22/08
to django-d...@googlegroups.com

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.

Regards,
Malcolm


Michael Elsdörfer

unread,
Jul 23, 2008, 6:09:14 AM7/23/08
to Django developers
> 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.

http://code.djangoproject.com/ticket/7913
Reply all
Reply to author
Forward
0 new messages