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