[Python-Dev] Dealing with test__locale failure on OS X before a3
bob at redivi.com
Fri Aug 27 06:59:06 CEST 2004
On Aug 26, 2004, at 11:33 PM, Brett C. wrote:
> Bob Ippolito wrote:
>> Well there are two ways to fix it:
>> 1) Call __setonlyClocaleconv() if it's there via weak linking or
>> whatnot around any setlocale or the like. This will at least affect
>> OS X 10.3, I'm not sure about 10.2, and the rumor says it's fixed
>> "now" in 10.4.
>> 2) Write a whole new module that uses Apple API for localization.
>> Obviously 2 is the "best" solution, but requires the most time. 1 is
>> easy-ish and will work reliably on all the machines that need it
>> (assuming the rumor is correct) unless Apple does something totally
>> strange and changes the behavior of a previous-release OS for reasons
>> other than security flaws :)
> OK, starting to sound like detecting __setonlyClocaleconv() in
> configure.in and using that info to deal with it is winning with other
> people, at least as an initial solution. Everyone else agree with
No. Don't use configure. The machine you compile Python with is not
necessarily the machine you will use Python with (for example,
compiling a 10.2 compatible Python and running on 10.4). Use dyld or
CFBundle API to look up the function dynamically, or use weak linking.
> I just checked and it looks like calling the function with a non-zero
> argument will force the locale back to "C" even if you just set it to
> a specific locale; so the function seems to force the locale to "C"
> and lock it down. So it will most likely need to be called right
> before the first setlocale call made by Python (I think it is in
> PyInitialize() ) and then not call it again.
Calling the function with a non-zero argument forces the locale to stay
at "C", and it returns the last value that was passed to it. I would
say that any Python function that depends on locale should do:
x = __setonlyClocaleconv(0)
# do python stuff carefully
Otherwise you will probably break CoreFoundation (which could break
just about anything, since nearly all Apple APIs depend on it).
Maybe this is just about as much work as writing a CoreFoundation based
locale module? I'm not sure which parts of Python are affected by
More information about the Python-Dev