Fredrik Lundh wrote:
>
> guido wrote:
> > I propose ustr(x) with the semantics given by Toby.
>
> +1 on concept.
>
> not sure about the name and the semantics.
Uhm, what's left then ;-) ?
> maybe a better name would be "unistr" (to match "unistr").
> or maybe that's backwards?
>
> how about "String" (!).
>
> (the perfect name is "string", but that appears to be reserved
> by someone else...)
>
> as for the semantics, note that __str__ is allowed to return a
> unicode string in the current code base ("str" converts it to 8-
> bit using the default encoding). ustr/unistr/String should pass
> that one right through:
>
> def ustr(s):
> if type(s) in (type(""), type(u"")):
> return s
> s = s.__str__()
> if type(s) in (type(""), type(u"")):
> return s
> raise "__str__ returned wrong type"
>
> > Class support (an __ustr__ method, with fallbacks on __str__
> > and __unicode__) would also be handy.
>
> -0 on this one (__str__ can already return either type, and if the
> goal is to get rid of both unichr and unistr in the future, we shouldn't
> add more hooks if we can avoid it. it's easier to remove stuff if you
> don't add them in the first place ;-)
Agreed. I'm just adding coercion support for instances using
that technique: instance defining __str__ can return Unicode
objects which will then be used by the implementation whereever
coercion to Unicode takes place.
I'll add a similar hook to unicode().
--
Marc-Andre Lemburg
______________________________________________________________________
Business: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4