A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2000-July/005717.html below:

[Python-Dev] Re: [I18n-sig] Unicode experience

[Python-Dev] Re: [I18n-sig] Unicode experienceFredrik Lundh fredrik@pythonware.com
Fri, 7 Jul 2000 14:30:51 +0200
guido wrote:
> I propose ustr(x) with the semantics given by Toby. 

+1 on concept.

not sure about the name and the semantics.

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 ;-)

</F>




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