From: Eric S. Raymond <esr@thyrsus.com>
Date: Sun, 25 Nov 2012 10:57:08 GMT
Subject: Re: Python extension commands in git - request for policy change
Message-ID: <20121125105707.GA25212@thyrsus.com>
In-Reply-To: <50B1F684.5020805@alum.mit.edu>

Michael Haggerty <mhagger@alum.mit.edu>:
> There is, of course, the awkward issue of how/when to transition to
> Python 3.x, which is *not* backwards compatible with Python 2.x.  I
> expect that when the time comes there will be volunteers (myself
> included) willing to help adapt Python scripts to the new version, but
> the problem shouldn't be minimized.

2to3 actually does a pretty good job.  It doesn't reduce the
transition cost to zero, but I find it does reduce that cost to an
easily manageable level even on quite large codebases.

> It would be insane to rewrite performance-critical C code in any
> scripting language, but there is a huge penumbra of code that is not
> performance critical and that mutates rapidly.

Indeed.  In the git architecture there is a pretty clear dividing line -
to a first approximation, plumbing should remain C but porcelain should
probably not.  (Not that I am advocating forcing such a move - but it would
be good to allow it to happen.)

The 80-20 rule (80% of the execution time is spent in 20% of the code)
helps us here.  The *other* 80% of the code can move to a scripting
language with no significant performance loss.  To find out what needs
to stay in C, run a profiler!
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>