I had yet *more* code fail which I felt sure was due to the locale issue. I added a print locale.getlocale() directly before the failing code. As expected, it indicated 'us' - but then the code started working. Digging into the source deeper, it becomes apparent that locale.getlocale() is useless for us here. If an external application has set the locale, locale.getlocale() will have the effect of *restoring* the locale to what Python previously thought it was. This value is then returned. [Also note that setlocale() leaks the "remembered" value each subsequent call to change the locale] Consider: * Python script calls locale.setlocale(LC_NUMERIC, "us") * _locale module remembers "us", but leaves with the CRT locale left to 'C' * Python script calls external function (MAPI). This changes the CRT locale. * Python script then calls locale.getlocale() to see what the locale is. * Python restores to the remembered 'us' from (1) above. It then queries the locale (which seems strange given it just set it!) 'us' is returned, and the locale has been changed back to it. However, we have no clue what the CRT thought the locale was. So that means all my investigation of how the locale changed underneath us via MAPI is completely invalid :( On the plus side, it seems that simply querying the current locale is enough to get the CRT back into whatever state a Python script ever set it to, and get stuff running again. Unfortunately, I'm having trouble working out exactly where that would be - but will fiddle a little more. Mark.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4