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
--
http://mail.python.org/mailman/listinfo/python-list
