[spambayes-dev] RE: [Python-Dev] RE: [Spambayes] Question (orpossibly a bug report)

[Christian Reis]

On Fri, Jul 25, 2003 at 07:25:48AM +0200, Martin v. Löwis wrote:
> "Mark Hammond" <mhammond at skippinet.com.au> writes:
> 
> > The "best" solution to this probably involves removing Python being
> > dependent on the locale - there is even an existing patch for that.
> 
> While the feature is desirable, I don't like the patch it all. It
> copies the relevant code of Gnome glib, and I
> a) doubt it works on all systems we care about, and

I'm sorry you don't like the patch, but if there's something that can be
fixed, we will fix it :-)

Well, glib is known to be quite portable, and we would make sure that it
does run on the supported platforms before considering checking it in.
(I'm betting it does.)

> b) is too much code for us to maintain, and

It's not *that* much code, and we can rely on fixes that are produced to
glib being easily ported to us -- we get free maintenance of the code
if we choose to do so, actually.

> c) introduces yet another license (although the true authors
>    of that code would be willing to relicense it)

Which means that c) is a non-issue?

> It would be better if system functions could be found for a
> locale-agnostic atof/strtod on all systems. For example, glibc
> has a strtod_l function, which expects a locale_t in addition
> to the char*.

Yes, but if all we were worried about was glibc, then point a) would be
a non-issue too. I imagine it's easier to make sure the code we *have*
runs on multiple platforms than trying to find and call code that *may*
exist on each given platform.

> It would be good if something similar was discovered for VC. Using
> undocumented or straight Win32 API functions would be fine.
> Unfortunately, the "true" source of atof (i.e. from conv.obj) is not
> shipped with MSVC :-(

I don't understand this bit. You'd rather use an undocumented API
function than an open source, well-tested, properly licensed set of
functions?

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL