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
-~----------~----~----~----~------~----~------~--~---

Reply via email to