Jorgen Grahn wrote: [snip] > > frailea> cat foo > import locale > print locale.getlocale() > locale.setlocale(locale.LC_CTYPE) > print locale.getlocale() > > When I paste it into an interactive Python session, the locale is already > set up correctly (which is what I suppose interactive mode /should/ do): > > >>> import locale > >>> print locale.getlocale() > ['sv_SE', 'ISO8859-1'] > >>> locale.setlocale(locale.LC_CTYPE) > 'sv_SE' > >>> print locale.getlocale() > ['sv_SE', 'ISO8859-1'] > >>> > > When I run it as a script it isn't though, and the setlocale() call does not > appear to fall back to looking at $LANG as it's supposed to(?), so my > LC_CTYPE remains in the POSIX locale: > > frailea> python foo > (None, None) > (None, None) > > The corresponding program written in C works as expected: > > frailea> cat foot.c > #include <stdio.h> > #include <locale.h> > int main(void) { > printf("%s\n", setlocale(LC_CTYPE, 0)); > printf("%s\n", setlocale(LC_CTYPE, "")); > printf("%s\n", setlocale(LC_CTYPE, 0)); > return 0; > } > frailea> ./foot > C > sv_SE > sv_SE > > So, is this my fault or Python's? I realize I could just adapt and set > $LC_CTYPE explicitly in my environment, but I don't want to capitulate for a > Python bug, if that's what this is.
Try locale.setlocale(locale.LC_CTYPE,"") as in your C program. It would be great if locale.setlocale with one parameter would be deprecated, because it suddenly acts like getlocale. It's unpythonic. By the way, since you took time to setup various LC_* variables there is no need to play with LC_CTYPE category. Just use the standard idiom. import locale locale.setlocale(LC_ALL,"") Serge. -- http://mail.python.org/mailman/listinfo/python-list