Comment 8 for bug 246983

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

LeoRochael wrote:
> There is a relatively simple fix for this problem.
>
> The last segment in the traceback above is caused by this small
> zope.tales.expressions.StringExpr.__call__() method on
> zope.tales-3.4.0-py2.6.egg/zope/tales/expressions.py:
>
> 258 def __call__(self, econtext):
> 259 vvals = []
> 260 for var in self._vars:
> 261 v = var(econtext)
> 262 vvals.append(v)
> 263 return self._expr % tuple(vvals)
>
>
> The problem is that self._expr is always a unicode string on recent versions of Zope2, whereas "self._vars" is a list of PathExpr objects, and "v = var(econtext)" will return whatever type of objects the path expressions resolve, even 8-bit strings. Which means the line "return self._expr % tuple(vvals)" will always cause a UnicodeDecodingError if any of the values is a string with 8-bit chars (save for Python default encoding tricks).
>
> If line 261 above is replaced by:
>
> v = econtext.evaluateText(var)
>
> In Zope2 this will return a Unicode object using the unicode conflict
> resolver registered with Zope2. In plain zope.tales, the
> zope.tales.tales.Context.evaluateText() method converts the object to
> unicode directly unless it is already a text-ish object (like a i18n
> message), which I believe is what makes sense in the context of String
> Expressions.
>
> I can commit a fix with tests based on this solution.

Can you upload a patch showing those tests? I'm afraid my seritonin
level is too low to figure out what you are fixing without seeing the tests.

Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 <email address hidden>
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAks9E8QACgkQ+gerLs4ltQ75ggCfS5KEFzqcRoZDdFwgp+HenZKp
yl8AoJZi1OCG/eTWnDsI4kG0xrB3SMTu
=IM2x
-----END PGP SIGNATURE-----