Re: Python extension commands in git - request for policy change
- From
Eric S. Raymond <esr@thyrsus.com>
- Date
- Nov 25, 2012, 09:53 UTC
- Message-ID
- <20121125095356.GA22279@thyrsus.com>
- In-Reply-To
- <CAMP44s18MzmWRNRiRjL6hvpK1cm=S-97fB2ep-_0RAhnfs5cvA@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com>:
> If your friends jump off a bridge, would you? Yes, using python has > served them well, but as opposed to what? Other scripting languages? I > don't think so.
The competition that Python won was *precisely* against other scripting languages, notably shell and Perl. Both used to be much more heavily used in system scripting than they are now.
> What if my extension only supports python 2.7? Or what if my extension > wants to support 2.0?
I propose that if 2.6 can't support it, then that should be considered grounds to reject it.
> Yes, they should _if_ they know what version they need. In my > extensions I really have no idea.
Then you shouldn't submit those extensions to be folded into core git.
Show 5 quoted lines
> > 3) We should be unconditionally be encouraging extensions to move > > from shell and Perl to Python. This would be a clear net gain is > > portability and maintainability. > > NO! It's up to the developer to choose what language to use,
I agree. You seem to be raising a lot of straw men. 'Encouragement' does not equate to beating anyone who makes an unpopular choice over the head.
I am also not suggesting that the whole git core ought to be hoicked over to Python. I was thinking mainly about extension subcommands, not what's in libgit now.
-- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>