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

Gustavo J A M Carneiro gjc at inescporto.pt
Tue Sep 2 00:08:11 EDT 2003


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 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.

  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>




More information about the Python-Dev mailing list