test__locale fails on MacOS X. It didn't with Python 2.3.

I've written a small C program that can reproduce the problem:


------------ testme.c -------
#include <locale.h>
#include <stdio.h>

int main(void)
{
        char* s;
        struct lconv* conv;

        s = setlocale(LC_NUMERIC, "it_IT");
        printf("setlocale returned: %s\n", s);

        conv = localeconv();
        printf("conv->decimal_point == %s", conv->decimal_point);

        return 0;
}
---------------

Compile this with 'cc -o testme testme.c' and it prints the right 
anwser. 

Compile this with 'cc -o testme testme.c -framework Foundation' or 
'cc -o testme testme.c -framework CoreServices' and it fails'

Python is linked with both frameworks....

Logged In: YES 
user_id=580910

Because this seems to be a bug in OSX I've filed a bug at 
bugreport.apple.com (radar#3754835)

Logged In: YES 
user_id=357491

Ah!  Nick Bastin and I were trying to solve this and noticed that in a 
straight C program it worked but under Python, no matter where you 
were, it was incorrect!  Thanks for the insight!

Logged In: YES 
user_id=580910

Many thanks to Bob Ippolito for finding what's going on...

It turns out that CoreFoundation.framework calls 
__setonlyClocaleconv when it is loaded. As the name suggests this 
breaks the locale API's. I don't know what whoever added this 
"functionality" was smoking, but at least he had enough sense to make it 
possible to restore functionality.

The prototype for __setonlyClocaleconv is: extern int 
__setonlyClocaleconv(int val);

Experimentation shows that setting val to a non-zero value breaks 
setlocale and setting it to 0 re-enables setlocale. The function returns the 
previous setting.

This means it is possible to create a workaround for this issue:

1) Add configure and/or weak-linking magic to detect the function
2) Call oldValue = __setonlyClocaleconv(0) before using a locale API
3) Call __setonlyClocaleconv(oldValue) after doing so.

Would such a patch be accepted?

Logged In: YES 
user_id=357491

I think modifying configure.in to detect the function is unnecessary; 
Darwin will be the only platform with it (Googling shows the CVS commit 
for Darwin that added the call to _CFInitialize() that probably set this 
whole problem off, so just blanket settting it (unless it is somehow new 
to OS X 10.3 or something) based on an ``#ifdef __APPLE__`` will 
probably be fine.  But knowing that function was explicitly added in a 
version would lead to requiring a configure.in check.

The next question becomes whether setting that value is a permanent 
settting in CoreFoundation until it is unloaded, or if it is just per run of an 
app.  If it is the former, then setting it period might be bad since that 
would affect other running apps.  But if Python is loaded against its own 
copy of CoreFoundation and it is local to Python then who cares; set the 
thing before any locale code is used and be done with it.

And as for accepting a patch, I know I would be happy with accepting it, 
but I would want Martin v. Lowis' input first to make sure this is the best 
thing to do.  Otherwise setlocale() should be changed to make it always 
raise an exception when __setonlyClocaleconv() is around.

Logged In: YES 
user_id=357491

I just talked to a friend of mine and it looks like the function is gone 
from Tiger so this might not be a problem in the future.

Plus, I don't know if we should be trying to work around this.  Perhaps 
we should try to do this the proper way using CF for locale support?  
Don't know.  At worst we should at least raise an exception for 
setlocale() .  This is getting OS X specific enough to need input from 
Jack, so assigning to him.

Logged In: YES 
user_id=580910

According to Bob the "feature" is present in the Tiger DP. I haven't 
checked this myself yet. I also haven't check older versions of the OS.

Logged In: YES 
user_id=357491

They must have removed it between the Tiger test release and now since 
my friend has checkin rights on that part of the tree at Apple.

Regardless, I am leaning towards having setlocale() raise an exception 
under OS X until we can possibly wrap CF stuff since 
__setonlyClocaleconv() is obviously not a public function and thus not 
meant for us to play with.

Logged In: YES 
user_id=357491

Started a thread to discuss trying to deal with this before 2.4.a3 .  Can 
be found at http://mail.python.org/pipermail/python-dev/2004-August/
048395.html .

Out-of-date?

It's probably out of date. I will check if it is still failing tonight
or tomorrow probably.