[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.

==============================================================
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.