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.