Malcolm, I found this thread, someone who claims to maintain the Python FAQ says it's OK to use the routine but(!) only in sitecustomize.py:
http://groups.google.com/group/comp.lang.python/browse_frm/thread/464dc112819e0098/75748feab89498bd?lnk=gst&q=sys.setdefaultencoding#75748feab89498bd I'm kind of confused now, ... Especially after reading PEP100: http://www.python.org/dev/peps/pep-0100/ Anyway I'll poke around, see if I can be of help with debugging. Cheers On Oct 14, 7:35 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Fri, 2007-10-12 at 10:10 +0200, Michal Konvalinka wrote: > > Hi group, > > I have a problem with this variable in > > django.contrib.admin.templates.admin.change_form.html > > {{ original|truncatewords:"18"|escape }} > > > I'm getting this error: > > >UnicodeEncodeErrorat /admin/player/playerprofile/5/ > > 'ascii' codec can't encode characters in position 3-4: ordinal not in > > range(128) > > > Unicode error hint > > The string that could not be encoded/decoded was: Tomá > > > Template error > > In template > > /develop/projects/test/django/django/contrib/admin/templates/admin/change_f > > orm.html, > > error at line 14 > > > When I comment the variable, it works. > > {# { original|truncatewords:"18"|escape } #} > > > Therefore I'm sure that problem is in the variable {{ original }} > > > Where can I get more information about this {{ original }} variable? I > > need to test it. There's no problem with it on my laptop running WinXP > > Python25 and latest django trunk. But there's a problem with it on > > FreeBSD, Python24 and latest django trunk. > > Hmm .. Kenneth Gonsalves reported this a week or two ago, and he was > using Python 2.4, also. I wasn't able to repeat the problem with Python > 2.4 on a recent Ubuntu, so it's up to people who are seeing it to help > debug further. > > What would be good to know is what bytes are in the string "original" > and which part of that sequence of filters is raising the error (I would > guess truncatewords(), but let's confirm that). Then try to track down > where "original" came from and why it isn't a unicode object. You may > need to spend some time tracing it back, but what *should* be happening > is that as soon as the data is read from the database (note that the > database backend you are using might be significant here, so note > version numbers, etc) it should be converted into a Python unicode > object and never changed back until output time (which is the phase you > are in). So now try to find where that assumption breaks down. > > This is an interesting problem, because now two unrelated people have > reported it *and* it's not universally repeatable. So if you can spend > some time poking around and trying to debug it, I'd appreciate it. I'm > laying money on a bug somewhere in the supporting pieces, rather than > Django, but it's something we have to work around, so we need to find > out the cause. > > Regards, > Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
