Re: Format strings
"Martin v. Löwis" <[email protected]> Wed, 30 Nov 2005 23:52:50 +0100
| Newsgroups | gmane.comp.python.internationalization |
|---|---|
| Message-ID | <[email protected]> |
Josef Spillner wrote: > But (my last remaining question, as it seems), the default encoding of = > unicode() is "ascii" instead of "utf-8" even for this particular source f= ile = > which specifies utf-8 encoding. > Would changing this to match the source file encoding break applications = as = > well? No. *That* would not be implementable (or, if somehow implemented, would break applications). In general, if you convert a Unicode string into a byte string, you cannot even be sure it originally came from source = code. Say you do a =3D u"Martin " b =3D u"v. " c =3D u"L=F6wis" mvl =3D a+b+c Now, the object mvl does not have any source code: so which encoding = should be used to encode it? If you have an answer: how does that change if I have mvl =3D mod1.a+mod2.b+mod3.c > Note that the documentation is not really helpful about this aspect. I'd = like = > to advocate for an i18n paragraph in the tutorial even, where such = > behavioural aspects are put into relation with each other, and explained = in = > the concept of modern (and legacy) runtime environment concepts. Contributions to the documentation is welcome. > Compare: > [All of its arguments should be 8-bit strings] > vs. > [if object is a Unicode string or subclass it will return that Unicode st= ring] > (actually it should say "Unicode object" below, right?) I personally use "Unicode string" (type unicode) vs. "byte string" (type str). Both are strings. > Is anyone coordinating the work, i.e. is there a "unicode compatibility s= tatus = > map" or anything similar? No. It is so far from actually working that nobody bothers to fix it. = However, if you have specific contributions which improve the state (i.e. have no behaviour change if -U is not specified, but fix a bug when it is), those are appreciated. Regards, Martin