Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#4435 closed (fixed)

[unicode] get_FIELD_display() does not work for None values

Reported by: mir@… Owned by: mtredinnick
Component: Database layer (models, ORM) Version: other branch
Severity: Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

If you have a model field with choices and null=True, the model function get_FIELD_display() returns u'None' if the attribute is None. It should return None

django.db.models.base, lines ~ 322 ff:

    def _get_FIELD_display(self, field):
        value = getattr(self, field.attname)
        return force_unicode(dict(field.choices).get(value, value))

Either this function, or force_unicode, needs a special check for None.

Change History (5)

comment:1 Changed 8 years ago by mir@…

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Version changed from SVN to other branch

comment:2 Changed 8 years ago by mtredinnick

  • Owner changed from adrian to mtredinnick
  • Triage Stage changed from Unreviewed to Accepted

We can't make force_unicode() do this by default, because it has to behave like str() in a bunch of places. I'll add a parameter to ignore such non-strings, though, just like smart_str() currently has. Then we can nail them one-by-one (there shouldn't be too many).

comment:3 Changed 8 years ago by mtredinnick

Change of mind to the previous comment. I cannot see anywhere at all that we are relying on mapping None -> 'None' via force_unicode. So special-casing None seems reasonable.

comment:4 Changed 8 years ago by mtredinnick

  • Resolution set to fixed
  • Status changed from new to closed

(In [5388]) unicode: Changed handling of None in smart_unicode/force_unicode. There is no
case when converting it to a unicode string seems useful, so keep it as None.
Fixed #4435.

comment:5 Changed 8 years ago by mtredinnick

(In [5400]) unicode: Reverted [5388] and fixed the problem in a different way. Checked
every occurrence of smart_unicode() and force_unicode() that was not previously
a str() call, so hopefully the problems will not reoccur. Fixed #4447. Refs #4435, #4430.

Note: See TracTickets for help on using tickets.
Back to Top