[ZCM] [ZC] 847/ 3 Resolve "(ZPT) UnicodeErrors are painful to debug"
"Collector: Zope Bugs, Features, and Patches ..." <[email protected]>
| Newsgroups | gmane.comp.web.zope.devel.collector-monitor |
|---|---|
| Message-ID | <[email protected]> |
Issue #847 Update (Resolve) "(ZPT) UnicodeErrors are painful to debug" Status Resolved, Zope/bug medium To followup, visit: http://www.zope.org/Collectors/Zope/847 ============================================================== = Resolve - Entry #3 by ajung on Jan 13, 2007 10:34 am Status: Pending => Resolved Unicode errors should be gone (mostly) with Zope 2.10.2. The related code contains enhanced logging that output the macro and the related string that causes the problem ________________________________________ = Comment - Entry #2 by dchandek on May 13, 2004 9:59 am This is still a problem in 2.7. I don't know what the best answer is, but conversion of non-standard ASCII values should (at least optionally) fail gracefully. Perhaps add a setting to zope.conf by which to control the unicode decoding error value (I assume that Zope uses the Python builtin unicode() ?). ________________________________________ = Request - Entry #1 by ctheune on Mar 11, 2003 5:13 pm When something slips within a ZPT that is not in XML Mode, and a native character (like german umlauts) not in ASCII, ZPT will hit you many times very hard. The biggest problem is that the UnicodeError happens in StringIO and you get no hint what failed. My typical solution looks like this: hack StringIO to make some printdebugging on the failing join (where some things that have not been unicode before get casted implicitly). Zope should provide an easier way to find the buggy string that caused this error. ==============================================================