Bug 529332
| Summary: | The EncodeUnicode filter no longer works. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Pierre Ossman <ossman> |
| Component: | python-cheetah | Assignee: | Mike Bonnet <mikeb> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 11 | CC: | mikeb, tyler |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 2.2.2-2.fc11 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-11-04 12:39:47 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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.
Digging through the tests, I also found this version:
unicode(t).encode('utf-8')
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. :/
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* A fixes have been applied upstream, and a new 2.2.2 build incorporating those fixes is available here: http://koji.fedoraproject.org/koji/buildinfo?buildID=137540 Please test it out and let me know if it solves your problem. python-cheetah-2.2.2-2.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/python-cheetah-2.2.2-2.fc11 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 I can confirm that the updated package solves the issue. Thanks for the hard work. 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. |
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).