On Tue, Jul 22, 2008 at 7:21 PM, Michael Elsdörfer
<[EMAIL PROTECTED]> 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.
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 %-)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
