I've been having an insane time trying to squash a weird unicode bug in Beertraq. This was one of the first bugs that was found after starting the beta and it's taken me this long to get it worked out. It all started with a cryptic-seeming error upon viewing the add-a-beer page:
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-9: ordinal not in range(128)
Real descriptive, right? Looking through the stack trace wasn't much help either. It was a bunch of stuff pertaining to trying to render the template. One thing I did notice is that a brewer with a unicode name had recently gotten added and this error was only happening on the new beer form (which includes a ChoiceField of brewers), but the brewer was being displayed just fine on its own page.
After asking my friend and fellow Django-user Dan-o what he thought, he asked if I had str() and unicode() defined in my models. I had str() defined (generally a good idea) but not unicode(). I popped it in to my Brewer model as so:
class Brewer(models.Model): TYPE_CHOICES = ( ('Macrobrewer', 'Macrobrewer'), ('Microbrewer', 'Microbrewer/Craft brewer'), ('Homebrewer', 'Homebrewer'), ('Unknown', 'Unknown'), ) name = models.CharField("Brewer name", max_length=255) brewer_type = models.CharField("Type of brewer", max_length=25, choices=TYPE_CHOICES) city = models.CharField("Brewer's city", max_length=255, blank=True) approved = models.BooleanField(default=False) def __str__(self): return self.name def __unicode__(self): return self.name class Meta: ordering = ['name']
And guess what? My problems went away. I feel like an idiot for being foiled by something so simple that I overlooked. It makes sense too because str() is used quite a bit in forms where the model instance's name needs to be magically generated. Without unicode() it would cause Django to barf on unicode names, just like it did on me.
Let this be a lesson to you. If you might EVER have ANY unicode text in your model instance's names, for crap's sake define _unicode_()!