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 [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-users?hl=en
-~----------~----~----~----~------~----~------~--~---
