This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: getdefaultlocale failure on OS X
Type: Stage:
Components: IDLE Versions: Python 2.3
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: brianl, loewis
Priority: normal Keywords:

Created on 2002-09-29 00:20 by brianl, last changed 2022-04-10 16:05 by admin. This issue is now closed.

Messages (10)
msg12526 - (view) Author: Brian Lenihan (brianl) Date: 2002-09-29 00:20
My OS X laptop did not have LANG  set in the bash
envrionment and idle (AquaTK) failed to launch with an
AttributeError in

            encoding = locale.getdefaultlocale()[1]
        except (ValueError, LookupError):

encoding = encoding.lower()

encoding is None here because locale.getdefaultlocale()
returns (None, None) when the locale can't be determined.

After finding that adding LANG=en_US to my .bashrc
didn't help, I Iearned OS X GUI apps don't use the
shell's environment, but do use whatever they find in
~/.MacOSX/environment.plist.  Adding a couple lines:


makes idle happy.   An alternative would be to make
sure encoding never gets set to None.

---   Sat Sep 28 17:17:02 2002
+++        Sat Sep 28 17:17:42 2002
@@ -64,7 +64,7 @@
         # which may give a clue. Unfortunately,
getdefaultlocale has
         # bugs that can cause ValueError.
-            encoding = locale.getdefaultlocale()[1]
+            encoding = locale.getdefaultlocale()[1] or
         except (ValueError, LookupError):


msg12527 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-09-29 22:17
Logged In: YES 

Can you please find out how to determine the user's
prefererred encoding on OS X?

Yes, getdefaultlocale is broken, but that is by design, and
cannot be fixed. So we should reduce its usage instead of
trying to correct it.
msg12528 - (view) Author: Brian Lenihan (brianl) Date: 2002-09-30 02:18
Logged In: YES 

I've done a little digging and have yet to find a
satisfactory answer.

This article: has
instructions for upgrading perl to 5.8.0

"OS X has one of the necessary environment variables set
(LANG), but without the above, you'll get annoying error
messages each time you try to run a script. The above
assumes the tcsh shell; if you prefer bash, use echo "export
LC_ALL=C" >> ~/.bash_profile instead."

I'll keep digging for a good answer, but I still believe
there is a bug here.  If you look in, you'll
see that encoding is given a default value of "ascii".   It
should leave the section with that value intact or with
ascii replaced with the proper locale.

The possibility that getdefaultlocale will punt and return
(None, None) is not taken into account in
msg12529 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-09-30 07:38
Logged In: YES 

I agree that there is a bug somewhere. I also suspect that
the bug is in IDLE, but I think it is wrong to fall-back to
ASCII on OS X (I'm almost certain that the user's encoding
is never just ASCII on that system). I suspect that it is
MacRoman or some such, but I also suspect that this either
might vary with the localized version of OS X (assuming
there are localized versions), or with a per-user setting.
msg12530 - (view) Author: Brian Lenihan (brianl) Date: 2002-09-30 08:35
Logged In: YES 

I was surprised falling back to ascii actually worked.  I
found a bunch of docs at the site.  As far
as I can tell, the proper way to fix this is to add the
necessary support to macglue.h, etc. so the functions in
_locale work on OS X as well.

I found out why this only just now bit me: I had compatible
libs in /usr/local/lib which made nl_langinfo() available in
_locale until I upgraded to 10.2.1.

The proper fix is going to require some effort by someone
who understands Apple API's much better than I do.

Since falling back to ascii works (at least for en_US) as
you intended - you were the one who added the locale code to - perhaps a temporary fix is to make sure the
fallback works as you intended?
msg12531 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-09-30 08:46
Logged In: YES 

Feel free to use any work-around you feel comfortable with.
However, I won't approve a fix that I know is wrong.
msg12532 - (view) Author: Brian Lenihan (brianl) Date: 2002-10-04 06:36
Logged In: YES 

This may as well be closed.  I see in the latest Python-dev
summary that Guido asked for all future changes to be done
in the idle-fork project.

Tony Lownds checked in a work-around to the idle-fork project
on 09/23 which is similar to what I was suggesting.
msg12533 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-10-04 07:28
Logged In: YES 

You can probably guess that I dislike the change being done
to IDLE. Oh well.
msg12534 - (view) Author: Brian Lenihan (brianl) Date: 2002-10-04 07:53
Logged In: YES 

I apologize it this comment reopens this bug.  Inititially,
I had a hard time understanding your objection, given that
my suggestion would have merely made the code behave as you
had intended when you wrote it.  Upon reflection, however, I
understand why you are objecting.
msg12535 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-10-04 09:21
Logged In: YES 

I guess we can leave this closed until a MacOS expert comes

To reiterate my opposition: I think it is wrong to use
'ascii' as the IDLE encoding on OS X. Even though OS X does
support ascii, it supports more than that. As a result,
people typing non-ASCII characters will find that IDLE
cannot process them properly. This is unfortunate, as IDLE
poses a restriction which no foundation in the system.
Date User Action Args
2022-04-10 16:05:42adminsetgithub: 37233
2002-09-29 00:20:20brianlcreate