On Fri, 2007-05-25 at 12:43 +0200, Michael Radziej wrote: [...] > I had another problem with force_unicode: It would turn > any SafeString into an unsafe Unicode. I was not > able to overwrite SafeString.__unicode__ (python seems > not to use __unicode__() when you call unicode() with an > encoding).
That's correct and logical in a way: when you pass in an encoding to unicode() you are asking for a decoder to be called on the string. When you don't pass in an encoding, you are asking the object to look after itself. The unicode() function is acting as a bit of a multi-method in that respect, which can be confusing at times, since they're not common in Python. > Thus, I modified force_unicode to use decode() instead, > and added proxy functions to SafeString. The code is > below. That looks reasonable. The change to force_unicode() shouldn't alter anything, functionality-wise. > Do you see any problems with this approach? I'm aware that I should > try to share the _proxy_method from SafeUnicode somehow, but > I'm still looking for the best way to do it. The _proxy_method() thing was a bit annoying to have to do in the first place. Looking at it now, I'm not sure why I added decode() to something proxying for a unicode type (or why we need encode() on a str proxy). So maybe we just need SafeUnicode.encode() and SafeStr.decode() and can code them directly. The current stuff looks very tricky and makes it look like I knew what I was doing, but I suspect the truth is otherwise. On review, I can't see why the simpler solution isn't better. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
