[Python-Dev] Re: Be Honest about LC_NUMERIC [REPOST] (original) (raw)
Gustavo J A M Carneiro gjc at inescporto.pt
Tue Sep 2 00:08:11 EDT 2003
- Previous message: [Python-Dev] Re: Be Honest about LC_NUMERIC [REPOST]
- Next message: [Python-Dev] Re: Be Honest about LC_NUMERIC [REPOST]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
A Seg, 2003-09-01 às 20:44, Christian Reis escreveu:
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 gasciiisupper(c) _ > ((gasciitable[(guchar) (c)] & GASCIIUPPER) != 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.
Actually, this code presentation is intentional, for the following two reasons: 1- I didn't want to accidentally introduce any bug, so I tried to copy-paste the code with as little changes as possible; 2- In the current form, if glib developers find any bug in this code, we can easily merge the changes back into python.
Perhaps I was wrong to have done it this way... Anyway, replacing the g* types is trivial with any decent text editor.
Regards.
-- Gustavo J. A. M. Carneiro <gjc at inescporto.pt> <gustavo at users.sourceforge.net>
- Previous message: [Python-Dev] Re: Be Honest about LC_NUMERIC [REPOST]
- Next message: [Python-Dev] Re: Be Honest about LC_NUMERIC [REPOST]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]