Re: Python extension commands in git - request for policy change
- From
Sitaram Chamarty <sitaramc@gmail.com>
- Date
- Dec 12, 2012, 00:09 UTC
- Message-ID
- <CAMK1S_hy8U0rVY=-u-QCqXjhn-6jwz5ofj_q_mbokVn8CGCMtw@mail.gmail.com>
- In-Reply-To
- <CACh33FrGPhaeNzZ2Tj5OxScecOPN13idw8TwU8Mf6o0KsAOB9A@mail.gmail.com>
On Tue, Dec 11, 2012 at 11:14 AM, Patrick Donnelly <batrick@batbytes.com> wrote:
Show 42 quoted lines
> Sorry I'm late to this party... > > I'm an Nmap developer that is casually interested in git development. > I've been lurking for a while and thought I'd post my thoughts on this > thread. > > On Sun, Nov 25, 2012 at 6:25 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote: >>> The most important issues to consider when imagining a future with a >>> hybrid of code in C and some scripting language "X" are: >>> >>> * Portability: is "X" available on all platforms targeted by git, in >>> usable and mutually-compatible versions? >>> >>> * Startup time: Is the time to start the "X" interpreter prohibitive? >>> (On my computer, "python -c pass", which starts the Python >>> interpreter and does nothing, takes about 24ms.) This overhead would >>> be incurred by every command that is not pure C. >>> >>> * Should the scripting language access the C functionality only by >>> calling pure-C executables or by dynamically or statically linking to >>> a binary module interface? If the former, then the granularity of >>> interactions between "X" and C is necessarily coarse, and "X" cannot >>> be used to implement anything but the outermost layer of >>> functionality. If the latter, then the way would be clear to >>> implement much more of git in "X" (and lua would also be worth >>> considering). >>> >>> * Learning curve for developers: how difficult is it for a typical git >>> developer to become conversant with "X", considering both (1) how >>> likely is it that the typical git developer already knows "X" and >>> (2) how straightforward and predictable is the language "X"? >>> In this category I think that Python has a huge advantage over >>> Perl, though certainly opinions will differ and Ruby would also be >>> a contender. >> >> * We might also need an embedded language variant, like Jeff's lua >> experiment. I'd be nice if "X" can also take this role. > > Lua has been an incredible success for Nmap [2](and other projects). > As an embedded scripting language, it's unrivaled in terms of ease of > embedding, ease of use for users, and performance. I would strongly > recommend the git developers to seriously consider it.
[snipping the rest; all valid points no doubt]
Does lua have os.putenv() yet? The inability to even *set* an env var before calling something else was a killer for me when I last tried it.
That may make it fine as an embedded language (called *by* something else) but it is a bit too "frugal" to use as a glue language (calls other things).