Flexible Collating (feedback please)

[Leo Kislov]

Ron Adam wrote:
> Leo Kislov wrote:
> > Ron Adam wrote:
> >
> >> locale.setlocale(locale.LC_ALL, '')  # use current locale settings
> >
> > It's not current locale settings, it's user's locale settings.
> > Application can actually use something else and you will overwrite
> > that. You can also affect (unexpectedly to the application)
> > time.strftime() and C extensions. So you should move this call into the
> > _test() function and put explanation into the documentation that
> > application should call locale.setlocale
>
> I'll experiment with this a bit, I was under the impression that local.strxfrm
> needed the locale set for it to work correctly.

Actually locale.strxfrm and all other functions in locale module work
as designed: they work in C locale before the first call to
locale.setlocale. This is by design, call to locale.setlocale should be
done by an application, not by a 3rd party module like your collation
module.

> Maybe it would be better to have two (or more) versions?  A string, unicode, and
> locale version or maybe add an option to __init__ to choose the behavior?

I don't think it should be two separate versions. Unicode support is
only a matter of code like this:

# in the constructor
self.encoding = locale.getpreferredencoding()

# class method
def strxfrm(self, s):
    if type(s) is unicode:
        return locale.strxfrm(s.encode(self.encoding,'replace')
    return locale.strxfrm(s)

and then instead of locale.strxfrm call self.strxfrm. And similar code
for locale.atof

> This was the reason for using locale.strxfrm. It should let it work with unicode
> strings from what I could figure out from the documents.
>
> Am I missing something?

strxfrm works only with byte strings encoded in the system encoding.

  -- Leo