You don't want to completely nix the setlocale(LC_CTYPE, "") call
though. The "" denotes to grab the native environment, in other words,
to grab whatever the current user's LC_CTYPE environment variable is set
to (see `locale -a`) and then set the program's LC_CTYPE to that.

Of course, this might be set to something that might be valid (e.g.
cy_GB.ISO8859-15), but has no matching entry in /usr/share/locale (or
wherever your system provides it) and as such it fails.

Reading SUS (The Single Unix Specification) I see that it explicitly says:

"Upon successful completion, setlocale() shall return the string
associated with the specified category for the new locale. Otherwise,
setlocale() shall return a null pointer and the locale of the process is
not changed."

So the patch seems to be correct actually. We try to setlocale(LC_CTYPE,
"") to grab a locale from the environment to set LC_CTYPE, but we fail
for whatever, so we should just pass since we should not adjust LC_CTYPE.

Mmm, but it seems setlocale() in locale.py is not adhering to the
standard by not allowing the "" case properly. _parse_localename() is
being overly pedantic about this by raising a ValueError.