Tom Christiansen <tchr...@perl.com> added the comment:
Raymond Hettinger <raymond.hettin...@gmail.com> added the comment:
> I would like to be involved in the design of the API for a UCA module
> and its routines for loading Unicode Collation Element Tables (not
> making the mistake of using global state like the locale module does).
Is this the problem where a locale is global to a process (or thread)?
The way I'm used to using the UCA module in Perl, that's never a problem,
because it's completely object-oriented. There's no global state. You
instantiate a collator object with all the state it needs, like
collation_level
upper_before_lower
backwards_levels
normalization
override_CJK
override_Hangul
katakana_before_hiragana
variable
locale
preprocess
And then you use that object for all your collation needs, including
not just sorting but also string comparison and even searches.
For example, you could instantiate a first collator object with its level
set to one, meaning just compare base alphanumerics not diacritics or case
or nonletters, and a second with the defaults so that it uses all four
levels or a different normalization. I have on occasion had more than one
collator object around at once each with its own locale, like if I want to
compare different locales' comparisons.
--tom
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12735>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
