[Python-Dev] Re: Be Honest about LC_NUMERIC [REPOST]

[Christian Reis]

On Mon, Sep 01, 2003 at 02:30:23PM -0400, Tim Peters wrote:
> > One of my early concerns (and I still have this concern) is that the
> > contributors here appear to take the position "We have this fine code
> > developed elsewhere, it seems to work, so we copy it. We don't
> > actually have to understand this code". I would feel more comfortable
> > if the code was written from scratch for usage in Python, with just
> > the ideas borrowed from glib. Proper attribution of contributors and
> > licensing are just one aspect, we really need the submitter of the
> > code fully understand it, and be capable of reacting to problems
> > quickly.
> 
> The patch is certainly more code than is needed to solve the part of the
> problem it does solve.  For example, things like
> 
> typedef char		gchar;
> typedef short		gshort;
> typedef long   		glong;
> typedef int    		gint;
> 
> introduce silly synonyms ("silly" == typing gshort instead of short does
> nothing except introduce possibilities for confusion); there are many
> definitions like
> 
> #define g_ascii_isupper(c) \
>   ((g_ascii_table[(guchar) (c)] & G_ASCII_UPPER) != 0)
> 
> that are never referenced; the code caters to C99's hexadecimal float
> literals but Python doesn't; and so on.  If someone who understood Python
> internals read my earlier two-sentence description of how the patch works,
> they could write something that works equally well for Python's purposes
> with a fraction of the code introduced by the patch.

I would certainly concede this point -- Gustavo's patch is a
proof-of-concept implementation. I do believe that the glib code is a
good starting point for an implementation, and the author has submitted
a written agreement, so the next step would be obtaining approval of the
general approach and then diving in to clean up and minimize the code as
much as possible.

The issue is whether a cleaned up patch is the way python-dev would like
this to go, or if another, perhaps orthogonal, approach -- such as the
conversion Guido has proposed -- would be preferrable.

> > The PEP should also point out deficiencies of the approach taken,
> > e.g. the issue of spelling NaN, inf, etc. If it can be determined not
> > to be an issue in real life (i.e. for all interesting platforms), this
> > should be documented as well.
> 
> Well, the patch doesn't even pretend to address other issues with
> portability of float literals.  They routinely come up on c.l.py, so of

Are these representations (NaN, infinity, etc) LC_NUMERIC-dependent? 
Or, more generally, locale-dependent?

As for the thread-safety issues, it's true, changing locale multiple
times in runtime is bound to confuse the conversion code (and
consequently the interpreter). One way around this would be a complete
reimplementation of the relevant functions, but here's betting that that
alternative would be shunned even more intensely.

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