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.

\malthe

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"z3c.pt" group.
To post to this group, send email to z3c_pt@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/z3c_pt?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to