Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

locale getlocale returns None on OSX

169 views
Skip to first unread message

Albert-Jan Roskam

unread,
Mar 12, 2014, 8:22:59 AM3/12/14
to Python
Hi,

locale.getlocale() sometimes returns (None, None) under OSX (Python 2, not sure about Python 3, but I think so). The problem is outlined here:
http://stackoverflow.com/questions/1629699/locale-getlocale-problems-on-osx

What is the cause of this? Is it limited to just Darwin systes? Does the 'horrible hack' solution on OS have any drawbacks? I like it better because it is not needed to set the LC_ALL environment variable prior to starting the Python program.

Regards,

Albert-Jan



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

All right, but apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, a

fresh water system, and public health, what have the Romans ever done for us?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Albert-Jan Roskam

unread,
Mar 12, 2014, 3:40:27 PM3/12/14
to Albert-Jan Roskam, Python

>________________________________
> From: Albert-Jan Roskam <fo...@yahoo.com>
>To: Python <pytho...@python.org>
>Sent: Wednesday, March 12, 2014 1:22 PM
>Subject: locale getlocale returns None on OSX


>
>
>Hi,
>
>locale.getlocale() sometimes returns (None, None) under OSX (Python 2, not sure about Python 3, but I think so). The problem is outlined here:
>http://stackoverflow.com/questions/1629699/locale-getlocale-problems-on-osx
>
>What is the cause of this? Is it limited to just Darwin systes? Does the 'horrible hack' solution on OS have any drawbacks? I like it better because it is not needed to set the LC_ALL environment variable prior to starting the Python program.
>
>Regards,
>
>Albert-Jan


Ok, here are some tests on my own system:

albertjan@debian:~$ uname -a
Linux debian 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux


Even if locale.setlocale is used first, OSX returns (None, None) when locale.getlocale() is called. Another thing that surprises me in the examples below is the output of the "python -c" example using Python 2.7. Isn't this supposed to be exactly equivalent to the code that follows?

# ======== Python 2.7 ========albertjan@debian:~$ python -c "import locale; locale.setlocale(locale.LC_ALL, ""); print(locale.getlocale())"

(None, None)   # <---- why is this?


albertjan@debian:~$ python
Python 2.7.3 (default, Jan  2 2013, 13:56:14)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
'en_US.UTF-8'
>>> locale.getlocale()
('en_US', 'UTF-8')  # <--- OSX (sometimes?) returns (None, None) here.

# ======== Python 3.3 ========
albertjan@debian:~$ python3 -c "import locale; locale.setlocale(locale.LC_ALL, ""); print(locale.getlocale())"
('en_US', 'UTF-8')

albertjan@debian:~$ python3
Python 3.3.4 (default, Feb 17 2014, 19:23:00)
[GCC 4.7.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
'en_US.UTF-8'
>>> locale.getlocale()
('en_US', 'UTF-8')

# ======== Pypy ========
albertjan@debian:~$ pypy -c "import locale; locale.setlocale(locale.LC_ALL, ""); print locale.getlocale()"
(None, None)

albertjan@debian:~$ pypy

Python 2.7.3 (87aa9de10f9ca71da9ab4a3d53e0ba176b67d086, Mar 10 2014, 14:07:15)
[PyPy 2.2.1 with GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``pypy is a better kind of
foolishness - lac''
>>>> import locale
>>>> locale.setlocale(locale.LC_ALL, "")
'en_US.UTF-8'
>>>> locale.getlocale()
('en_US', 'UTF-8')

Ned Deily

unread,
Mar 12, 2014, 4:43:44 PM3/12/14
to pytho...@python.org
In article
<1394626979.4688...@web163806.mail.gq1.yahoo.com>,
Albert-Jan Roskam <fo...@yahoo.com> wrote:
> locale.getlocale() sometimes returns (None, None) under OSX (Python 2, not
> sure about Python 3, but I think so). The problem is outlined here:
> http://stackoverflow.com/questions/1629699/locale-getlocale-problems-on-osx

Python's locale uses the plaform's locale implementation and POSIX
locale is an old and somewhat weird animal. Make sure you thoroughly
read the description of the locale module, in particular, the caveats
section:

http://docs.python.org/2/library/locale.html#background-details-hints-tip
s-and-caveats

The first gotcha is that you need to explicitly call
locale.setlocale("LC_ALL,"") to get the preferred locale environment, as
either specified by the user, by LANG or other LC_* environment
variables, or the platform defaults. In general, OS X does not provide
a default for your process. However, various environments do. The OS X
Terminal.app has profile settings (Preferences -> Settings -> (Profile
name) -> Advanced) to specific a character encoding and a checkbox to
"Set locale environment variables on startup". With that set properly,
programs run under Terminal.app will see LANG set. The user can also
set an explicit LANG value in a shell profile, like .profile or .bashrc,
but those only apply when a shell is being used. Depending on which
profile it is set in, that might not work under all conditions, like
under "sudo" or in an "ssh" session. Setting an env variable in a shell
profile would also not apply to an double-clickable app bundle since no
shell is involved in launching it; it is possible to set environment
variables in the app's Info.plist, though.

> What is the cause of this? Is it limited to just Darwin systes? Does the
> 'horrible hack' solution on OS have any drawbacks? I like it better because
> it is not needed to set the LC_ALL environment variable prior to starting the
> Python program.

As the caveats section points out, setting locale env vars may have
unwanted side effects on other parts of the process it is running in or
creates. So, if you are using it in a standalone program, it may be OK.
If you are using it a module intended to be used by other programs, you
probably shouldn't be changing something that could break other parts of
the calling program.

--
Ned Deily,
n...@acm.org

0 new messages