setlocale() in a module/extension library

[Damien Elmes]

Hi folks,

I've got a module + C extension which provides on screen display
support in X, via libxosd (http://repose.cx/pyosd). I've recently had
a report of trouble where a Russian user was unable to display any
Russian text.

I've managed to resolve the issue by inserting the following two
lines at the start of the application:

import locale
locale.setlocale(locale.LC_ALL, "")

.. which I presume alters the way the Russian text is passed to X by
the underlying library.

My question is this: it would be nice if every user of my library
didn't need to add the above two lines to their code. But on the other
hand, I'm unsure of the implications of modifying the locale from
within a module, and it doesn't seem very clean. Would calling
setlocale() from a library be a bad thing? If so, any alternative
recommendations would be greatly welcome.

Kind regards,

Damien

[Jarek Zgoda]

Damien Elmes napisał(a):

> My question is this: it would be nice if every user of my library
> didn't need to add the above two lines to their code. But on the other
> hand, I'm unsure of the implications of modifying the locale from
> within a module, and it doesn't seem very clean. Would calling
> setlocale() from a library be a bad thing? If so, any alternative
> recommendations would be greatly welcome.

I think that many of them does that already, just to get proper display
on terminals, proper timezone settings etc. Anyway, setting locale in
library doesn't seem to be good, as this may change locale in global
application environment (what if user on system with Russian locale sets
application locale to de_DE to have german timezone settings?).

--
Jarek Zgoda
http://jpa.berlios.de/

["Martin v. Löwis"]

Damien Elmes wrote:
> My question is this: it would be nice if every user of my library
> didn't need to add the above two lines to their code. But on the other
> hand, I'm unsure of the implications of modifying the locale from
> within a module, and it doesn't seem very clean. Would calling
> setlocale() from a library be a bad thing? If so, any alternative
> recommendations would be greatly welcome.

Because the locale is a process-wide setting, libraries have typically
abstained from setting it. One of the most prominent problems is that
setlocale is not thread-safe, so you need to do it before any threads
are started. Another issue, of course, is that applications might break
if the locale changes "in the middle" of some computation, as a side
effect of using some library.

Therefore, the C tradition is to indeed require applications to the
the locale explicitly. Python follows that convention, and again exposes
just the API, with no automatic setting of the locale (actually, there
is some such setting during startup, but that is reverted before
__main__ starts executing).

IOW: feel free to invoke setlocale in your library. It will likely
work in many cases, but may break in some. So you should atleast
document that this is what your library does.

Regards,
Martin

[Damien Elmes]

"Martin v. Löwis" <mar...@v.loewis.de> writes:

> IOW: feel free to invoke setlocale in your library. It will likely
> work in many cases, but may break in some. So you should atleast
> document that this is what your library does.

Thanks for the advice. I ended up implementing it in the library, with
an option to disable it and a note in the documentation directing
people to call setlocale() manually if they run a threaded
application, or if they wish to set up their own locale.

Thanks again,

Damien