On 12/1/06, Gábor Farkas <[EMAIL PROTECTED]> wrote: > what about the following change?: > > if not isinstance(output, basestring): > > - return str(output) > > + try: > > + return str(output) > > + except UnicodeEncodeError: > > + return unicode(output).encode(settings.DEFAULT_CHARSET) > > elif isinstance(output, unicode): > > return output.encode(settings.DEFAULT_CHARSET) > > from the python docs (http://docs.python.org/lib/built-in-funcs.html) > unicode() technically should not work in this case, but it somehow works :) > > this change would not introduce any backward incompatibility, > because this new code is only triggered when the old one failed. > > another (independent from this change) enhancement would be to add an > __unicode__ method to the Form object.
This is an interesting problem. That template fix would be OK by me, but it's sort of a hack. I think we're going to run into similar issues with Form.__str__() returning a Unicode object. Maybe, as you suggest, Form.__str__() should return a bytestring according to DEFAULT_CHARSET, and we could add a Form.__unicode__() that would return it as Unicode. Thoughts? And would that approach mix well with the upcoming Python 3000 changes? I thought I read something about __unicode__ and __str__ merging... Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
