Bug: (Locale) IDLE/Tkinter/Python?

[Guido van Rossum]

> > What embedding code?  I thought you were using IDLE.  Are you saying
> > that you are using IDLE from an embedding application?
> 
> Why not? It's useful for interactively testing inbuilt extension modules.
> These are built into the code and initialised before calling any Python
> scripts we run.

I'm not complaining that you do it, I'm just requesting that you make
this clear.  It's like calling tech support for a laptop -- the first
thing they ask you is if you have any 3rd party hardware installed.

> I would have like to embed PythonWin (the debgger is better, especially
> in the latest release), but it doesn't want to work. Perhaps this is
> because the embedding app isn't MFC. I'm not too sure about this one.

Probably.  IDLE's debugger will eventually match Pythonwin's though,
when I get back to it.  (Mark & I share code, so I don't want to
predict which one will be better in the long run.)

> > (It is always necessary if any 3rd party C code is involved when
> > reporting a Python problem; embedding counts as such :-)
> 
> I see. I thought, since the ability to do this was there, it would be
> okay to use it. :-)

Yes, but see before.

> > If so, why do you call setlocale(LC_ALL, "")?
> 
> The rest of the code relies on it. (e.g. to set the decimal point
> separator for internationalisation purposes.

OK.

> > There may be no good solution if your embedding application needs to
> > do that -- there are too many places in the Python runtime that expect
> > the locale to be C.
> 
> So how come it's okay to set the locale in Python. Surely this just calls
> the equivalent function in C.

Read the code.  It saves and restores the locale.

> Perhaps if I call setlocale(LC_ALL, "C") before I initialise Python, then
> call Python's setlocale() with the original locale before I run any scripts.

That would make the Python code honor the locale but your C code
would see the C locale.

> > I suppose this could be fixed by not using any of those, but (a) it's
> painful
> > to write your own atof(), %e, %f, %g formatter in a platform independent
> > manner with the best accuracy, (b) it seems such a waste of effort since
> the
> > C library has one, (c) finding and fixing all locale dependencies (there
> are
> > others!) in the Python source code is about as much fun as systematically
> > searching for Y2K bugs in a program of similar size.
> 
> This almost implies that Python's version of setlocale() does something
> completely different from the C version.

Yes.  Read _locale.c for details.

(Sorry the answer isn't better -- the problem is the locale model
imposed by the C standard, which doesn't support using different
locales easily.  It also doesn't support different locales in diffent
threads -- at least the standard is silent on the issue, and vendors'
implementations differ.  See Martin von Loewis' talk at an early
Python conference -- it's on python.org.)

--Guido van Rossum (home page: http://www.python.org/~guido/)