[spambayes-dev] RE: [Spambayes] Question (or possibly a bug report)

Mark Hammond mhammond at skippinet.com.au
Thu Jul 24 16:03:55 EDT 2003

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]

* 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
* 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.


More information about the spambayes-dev mailing list