Can't see values of PositiveSmallIntegerField in admin after adding the field to list_display.

[minder]

Django 1.0.2, Python 2.5.2
I have a model with PositiveSmallIntegerField. I added this field to list_display in model's admin but I can't see any values in the column, only "(None)". I know I can write a simple function to convert the type, but this should not be required imho. Strings, dates and boolean are handled good - why numbers are not?

models.py:

from django.db import models

MEALS=(
('0','Own'),
('1','1'),
('2','2'),
('3','3'),
)

class Person(models.Model):
	first_name = models.CharField(max_length=20)
	last_name = models.CharField(max_length=30)
	email = models.EmailField()
	meals = models.PositiveSmallIntegerField(default=0, choices=MEALS)
	verified = models.BooleanField()

	def __unicode__(self):
		return self.first_name + ' ' + self.last_name

admin.py:

from django.contrib import admin
from myproject.myapp.models import Person


class PersonAdmin(admin.ModelAdmin):
	list_display = ('first_name', 'last_name', 'email', 'meals', 'verified',)
	list_display_links = ('first_name', 'last_name',)
	search_fields = ('first_name', 'last_name', 'email',)
	list_filter = ('verified',)

admin.site.register(Person, PersonAdmin)

[arien]

You're storing strings that look like integers (the first element of each MEALS tuple) in a PositiveSmallIntegerField. Fix this inconsistency and the problem goes away.

For fields with choices, the admin will try to use the "human-readable" representation of the field's value. If the admin doesn't find the field's value (an integer in your case) as the first element in one of the tuples in the list of choices (strings in your case), it will use (None) as the human-readable representation.

(See ​django.contrib.admin.templatetags.admin_list.item_for_result for the details if you're curious.)

[Scot Hacker]

This could really use a mention in the list_display documentation. Patch attached.

[Scot Hacker]

Documentation of need to use real integers in CHOICES tuples for list_display.

[James Bennett]

I'd prefer that we leave it as assumed that stuffing strings into a numeric field type can cause problems.

[Scot Hacker]

I think it's worth documenting because strings are valid keys in CHOICES, so this catches people unexpectedly. The reality is that you can't use a string that happens to look like an integer even if you want to. The docs don't say that, so the developer ends up thinking something is wrong with they way they've set up list_display when the problem really is that Django doesn't allow any old string as a CHOICES key.

[James Bennett]

Any Python data type can, technically, be used here. What you're supposed to do is use values of the type that's appropriate for the field they go in. If your database accepts other types of data there, that's your DB's fault in part, but really the lesson here is that the values need to be valid for the field type. Which, hopefully, is obvious.