2008/10/26 Hanno Schlichting <[EMAIL PROTECTED]>:
> Didn't we decide to drop support for non-unicode string insertion
> already? I was under the impression that we shouldn't deal with encoding
> conversions at all inside the machinery. zope.tal and friends have a
> clear Unicode-only policy as well.
There is the odd exception of int; it really does make sense to
support it natively (in my view).
> should be enough, shouldn't it? Feel free to experiment with using
> __unicode__ instead, but I have a feeling that checking for the
> attribute existence, checking if it is a callable and calling it, is
> more expensive.
Here's my usecase:
I have this "error" object, which has a ``messages`` attribute
(containing zero or more errors), but I'd also like it to be useful by
itself; so I'd give the error-object a ``__unicode__``-method and it
work "just work" (perhaps concatenate the errors or something).
Let me test the speed implications; certainly if it has any serious
impact, we can't justify it. Perhaps something like this:
1. isinstance unicode
2. isinstance str (we currently do support this, but maybe shouldn't)
3. getattr __unicode__
4. coerce to str/unicode
This approach should have no performance penalties for the common
case, but it would support my case, too.
You received this message because you are subscribed to the Google Groups
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at