Re: Python extension commands in git - request for policy change
- From
Eric S. Raymond <esr@thyrsus.com>
- Date
- Nov 25, 2012, 10:57 UTC
- Message-ID
- <20121125105707.GA25212@thyrsus.com>
- In-Reply-To
- <50B1F684.5020805@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu>:
Show 5 quoted lines
> 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>