this came up on #ubuntu-devel; Debian and Ubuntu do not generate all libc locales by default, so it is likely that 

$ LC_ALL=en_US.UTF-8 python -c "import locale; locale.setlocale(locale.LC_ALL, '')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.5/locale.py", line 476, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

fails on a system (often experienced ssh'ing into a server system where your current locale doesn't exist). Examples for bug reports in various applications are:

  https://launchpad.net/bugs/91583 (apt-listchanges)
  https://launchpad.net/bugs/88638 (pitivi)
  https://launchpad.net/bugs/81556 (exaile)
  https://launchpad.net/bugs/90525 (hwdb-client)

In C, the result of the setlocale(3) call can be, and usually is ignored, if the locale cannot be set.

It is argued that the Python interface for locale.setlocale() should not raise an exception by default, if the locale is missing on the system.

That would be an behaviour change of locale.setlocale(), so the original behavour should be kept as an option (introducing an optional third parameter to raise the exception when the locale doesn't exist). Is this an appropriate change, or could another change be suggested?

Not raising an exception if an operation failed violates the Zen of Python (errors should never pass silently, unless explicitly silenced). So explicit silencing is necessary, but if so, it's easy enough to explicitly catch the exception:

try:
  locale.setlocale(..)
except locale.Error:
  pass

If the intention is that all software on Debian works successfully even if the locale is configured incorrectly, then an automated build system should perform all builds in a non-existing locale, and see if anything fails.

-1  

I prefer explicit exception. If needed, it is not hard to catch and ignore the exception. 

If this were actually a true error, I'd agree with you, but it isn't. For most programs (that just do locale.setlocale(locale.LC_ALL, '') to switch on internationalisation), it's a warning, not an error; in the common case there is no reason for them to fail.

If you still insist that this has to be treated as an error, how about adding locale.enable_i18n or something for the common case that does:

  try:
      locale.setlocale(locale.LC_ALL, '')
  except locale.Error:
      pass

Because, in practice, many programs appear not to bother catching the exception, and because the programmer is typically using an environment with a properly configured locale they won't notice. It's only when you're in an environment such as sshing (with SendEnv) to a remote system that doesn't have your locale configured that you notice that C programs continue to function correctly, Perl programs issue a warning on stderr, but Python programs crash. While noticing errors is a good thing in general, it seems to go a bit far here.

How can you say it's not an error? The function does not achieve what it attempts to.

Adding another function with a different semantics is fine to me, although I doubt it helps: the existing code calls setlocale, not that other function.

Is this still an issue on Debian and Ubuntu?

Yes, the same symptoms are still present.

I'd argue that it generally isn't an error in practice for applications, and thus the net effect of this exception is negative; it's extraordinarily rare for a crash to be preferable to running without localisation.  Adding a new function would help because I think it would be easier to persuade people to call a new function that just does what they want ("turn on localisation if possible") than to catch an exception (at which point they have to think "hm, could that exception be for some other reason than you-just-don't-have-that-locale", etc.).

Certainly at a minimum, the docs should describe the exception and workaround instead of just:

"setlocale() is not thread safe on most systems. Applications typically start with a call of

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

This sets the locale for all categories to the user’s default setting (typically specified in the LANG environment variable). If the locale is not changed thereafter, using multithreading should not cause problems."

+0 for a new function in Python 3.2.

For Python 2.7 though, we can't really add that new function or change the behavior of setlocale() so I'm not sure what the right thing to do is.  A documentation change is probably as good as it's going to get for Python 2.