Hello, I think I might have a similar problem. Or at least it seems to be a Unicode thing. Unfortunately, however, I cannot switch to the unicode-branch, because I'm stuck to the ports (version 0.96 ATM).
I am comparing the value stored in the model (database) with the value coming in from a form. They *are* equal (since the string was stored in the db before). Python/Django however thinks different: /domains/ouwepikouwepijp.nl/python/opop/uploads/upload.py:98: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal if not (default_movies[i].name == self.clean_data['name%d' % (i+1)]): What can I do to prevent this Unicode Warning? (while sticking to version 0.96?) best, dirk On 22-jun-2007, at 9:23, patrick k. wrote: > > thanks for your answer. I´ve been trying to solve this for about 8 > hours ... finally giving up. > so, I´ll switch to the unicode-branch. > > Am 22.06.2007 um 02:02 schrieb Malcolm Tredinnick: > >> >> On Thu, 2007-06-21 at 16:23 +0200, va:patrick.kranzlmueller wrote: >>> the code below does not give a validation error when typing umlauts, >>> but the umlauts are not saved to the database. >>> >>> al_re = re.compile(r'^\w+$', re.UNICODE) >>> >>> def clean_last_name(self): >>> if 'last_name' in self.cleaned_data: >>> if not al_re.search(self.cleaned_data['last_name']): >>> raise forms.ValidationError('Error message.') >>> return self.cleaned_data['last_name'] >>> >>> when doing "print self.cleaned_data" I´m getting this: >>> 'last_name': u'M\xfcller', >>> >>> how am I supposed to deal with umlautes when using newforms? >>> btw: all our data is utf-8 >> >> There are lots of little bugs like this on trunk at the moment. If >> you >> want to use non-ASCII characters, switch to using the Unicode branch. >> It's completely up-to-date with trunk (merged about twice a week, >> providing there are no risky changes on trunk that haven't settled). >> >> Part of the problem is that newforms (on trunk) tries hard to be >> unicode-aware, but the transition from unicode to byestrings is not >> handled well in other places in the framework. That is why we are >> making >> all the changes on Unicode branch (which will soon be on trunk). >> >> Regards, >> Malcolm >> >> >> >>> > > > > > ----------------------------- Dirk van Oosterbosch de Wittenstraat 225 1052 AT Amsterdam the Netherlands http://labs.ixopusada.com ----------------------------- --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---