Bug 529332 - The EncodeUnicode filter no longer works.
Summary: The EncodeUnicode filter no longer works.
Alias: None
Product: Fedora
Classification: Fedora
Component: python-cheetah
Version: 11
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Mike Bonnet
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2009-10-16 09:09 UTC by Pierre Ossman
Modified: 2009-11-04 12:39 UTC (History)
2 users (show)

Fixed In Version: 2.2.2-2.fc11
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-11-04 12:39:47 UTC
Type: ---

Attachments (Terms of Use)

Description Pierre Ossman 2009-10-16 09:09:46 UTC
The following code used to work just fine in previous versions of Cheetah:

t = Template(file="foo.tmpl", filter="EncodeUnicode")
t.var = u"Text with some non-ascii characters: åäö"

print t

With the current version, this results in:

Traceback (most recent call last):
  File "summary.py", line 92, in <module>
    print t
  File "/usr/lib64/python2.6/site-packages/Cheetah/Template.py", line 1004, in __str__
    return getattr(self, mainMethName)()
  File "_home_ossman_devel_web_html_aboutus_press_summary_tmpl.py", line 115, in respond
  File "/usr/lib64/python2.6/site-packages/Cheetah/DummyTransaction.py", line 47, in getvalue
    (%s)''' % (nonunicode, ex))
DummyResponseFailure: Looks like you're trying to mix encoded strings with Unicode strings
            (most likely utf-8 encoded ones)

            This can happen if you're using the `EncodeUnicode` filter, or if you're manually
            encoding strings as utf-8 before passing them in on the searchList (possible offenders: 

It seems like the bug is that it has started running the input variables through the filter, but it still expects everything to be unicode internally (which it of course isn't since the filter transformed it).

Comment 1 Mike Bonnet 2009-10-16 14:12:36 UTC
The workaround is to not use the EncodeUnicode filter, and use t.respond().encode('utf-8') to generate UTF-8 output.  I'm discussing how to handle this in general with the upstream developers.

Comment 2 Pierre Ossman 2009-10-16 14:49:00 UTC
Digging through the tests, I also found this version:


It's a bit of a problem when a previously working method breaks though. I have a lot of scripts that need to be changed. I also seem to recall that "my" method was the recommended one for handling unicode. :/

Comment 3 R. Tyler Ballance 2009-10-19 00:42:18 UTC
Mike and I worked out a resolution for this issue which will definitely be going into the Cheetah 2.4.0 release (next release up, jumping some version numbers ;))

I believe Mike was planning on backporting it to the RedHat v2.2.2 package. 

*adds self to CC*

Comment 4 Mike Bonnet 2009-10-20 18:25:09 UTC
A fixes have been applied upstream, and a new 2.2.2 build incorporating those fixes is available here:


Please test it out and let me know if it solves your problem.

Comment 5 Fedora Update System 2009-10-20 18:29:53 UTC
python-cheetah-2.2.2-2.fc11 has been submitted as an update for Fedora 11.

Comment 6 Fedora Update System 2009-10-27 06:45:28 UTC
python-cheetah-2.2.2-2.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update python-cheetah'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10765

Comment 7 Pierre Ossman 2009-11-03 13:36:57 UTC
I can confirm that the updated package solves the issue. Thanks for the hard work.

Comment 8 Fedora Update System 2009-11-04 12:39:41 UTC
python-cheetah-2.2.2-2.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.