[spambayes-dev] Config files and locale

[Mark Hammond]

> > If an application ever wants to ship a configuration file that
> > includes a floating point number, we *must* assume an 'en' locale,
> > (as we will be shipping 'x.x' in the file).
>
> Not quite:  we must assume the "C" locale.  This is what
> Americans think of
> as being the right thing for numbers, but thinking of it as 'en' truly
> confuses the requirement:  Python works very hard to make sure the
> LC_NUMERIC category remains in the "C" locale, even if you use
> locale.setlocale() to *try* to set LC_NUMERIC to "en" (or to
> anything else).
> Python can get screwed, though, by C code outside of Python's
> calling C
> setlocale() itself.

As per the other thread, this is becoming perfectly clear <wink>.  But I
think this is a different issue.  Let's assume a "perfect" locale based
world, where neither Python made any assumption about the locale, nor did
any external application ever change it.

Even in this perfect world, we have the same issue:  If we ever want to ship
a config file containing floats, we must agree on either periods or commas
as the decimal.  If we do that, we prevent the user entering numbers using
their regional settings, if that differs from what we decide.

So even in this perfect world, the "OptionsClass" module assuming locale
specific formatting of numbers appears flawed.

> > Refuse to allow both a period and a comma in a number.  If either is
> > given, assume it is the decimal.  Always write the config
> file in 'us'
> > format.  There are a few variations on this we could take, depending
> > on what we wanted to support, but I thought I would get it out there
> > for discussion first.
> >
> > Any thoughts?
>
> It may be a start, but I'm afraid it's impossible to solve
> all the deep
> problems without changing the Python implementation.

As I mention, I think this is discrete from the other issues.  A simple
number parser *just* for our config files, so that we can ship
locale-independent config files, even at the cost of accuracy, seems
reasonable.

Mark.