[Python-Dev] logging module broken because of locale
"Martin v. Löwis"
martin at v.loewis.de
Tue Jul 18 21:26:28 CEST 2006
James Y Knight wrote:
> That seems backwards of how it should be ideally: the byte-string upper
> and lower should always do ascii uppering-and-lowering, and the unicode
> ones should do it according to locale. Perhaps that can be cleaned up in
> py3k?
Cleaned-up, yes. But it is currently not backwards.
For a byte string, you need an encoding, which comes from the locale.
So for byte strings, case-conversion *has* to be locale-aware (in
principle, making it encoding-aware only would almost suffice, but
there is no universal API for that).
OTOH, for Unicode, due to the unification, case-conversion mostly
does not need to be locale-aware. Nearly all case-conversions are
only script-dependent, not language-dependent. So it is nearly possible
to make case-conversion locale-independent, and that is what Python
provides.
The "nearly" above refers to *very* few exceptions, in *very*
few languages. Most of the details are collected in UAX#21, some
highlights are:
- case conversions are not always reversible
- sometimes, case conversion may convert a single
character to multiple characters; the canonical
example is German ß (considered lower-case) -> "SS"
(historically, this is just typographical, since there
is no upper case sharp s in our script)
- sometimes, conversion depends on the position of
the letter in the word, see Final_Sigma
in SpecialCasing.txt, or on the subsequent
combining accents, see Lithuanian More_Above
I believe the unicode.lower behaviour is currently right
for most applications, so it should continue to be the
default. An additional locale-aware version should be added,
but that probably means to incorporate ICU into Python,
to get this and other locale properties right in a
platform-independent fashion.
Regards,
Martin
More information about the Python-Dev
mailing list