Adrian Holovaty wrote: > Hello all, > > I've attached the first draft implementation of the manipulator > replacement framework -- it's just a single Python module.<snip> > > * All output is Unicode. I did this because eventually Django's > internal strings will all be Unicode, and we might as well do that > from the start with this. >
> # Default encoding for input byte strings. > DEFAULT_ENCODING = 'utf-8' # TODO: First look at django.conf.settings, then > fall back to this. > > def smart_unicode(s): > if not isinstance(s, unicode): > s = unicode(s, DEFAULT_ENCODING) > return s > hi, regarding the fallback-logic... what is the goal of the unicode conversion? should it be a never-failing operation? because if yes, then we need to fall-back to a never-failing charset, like iso-8859-1. means we would have a logic like: - try django.conf.settings - if fails, try UTF-8 - if fails, try ISO-8859-1 but, if we allow the situation where the form-processing can fail with an unicode-error, then imho we should not fall-back at all. just use the setting in django.conf.settings. or, what about the following approach: - add an optional "encoding" parameter to the Form-constructor, which would default to django.conf.settings. - and don't have any unicode-fallback what do you think? gabor --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" 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-developers -~----------~----~----~----~------~----~------~--~---
