Adrian Holovaty wrote: > Hi Ivan, > > Could you explain again why you think newforms should output > clean_data as bytestrings rather than Unicode strings?
I don't think so :-). Quite the opposite. I think it's good that you made newforms in unicode since it effectively gives a start to unicodification and lets us test it early. But there is one issue that is very annoying: when newform saves data to a model instance it fills it with unicode. This creates some issues: - part of the time an object stores bytes (when loaded from db), part of the time -- unicode (when updated from newforms) - __str__s return unicode instead of str - some backends versions can't handle unicode and try to implicitly str() in ascii it with UnicodeEncodeError's The patch that I'm advocating for here does one little thing: when a newform saves an instance it converts unicode into DEFAULT_CHARSET. In other words it makes newforms do decode/encode on both their boundaries: not only on the side facing the web (POSTs, templates) but also on db side. > Are you suggesting that we would convert newforms > clean_data *back* to being Unicode *after* we convert the rest of the > framework to be Unicode-aware? No, clean_data will remain in unicode (and for good). Encoding happens only when clean_data is actually applied to a model instance. > I apologize in advance if you've already brought this up and explained > it. Just trying to understand your thinking here. Yeah, I understand that this thread is rather long :-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
