Re: Python extension commands in git - request for policy change

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Nov 25, 2012, 08:53 UTC
Message-ID: <CAMP44s18MzmWRNRiRjL6hvpK1cm=S-97fB2ep-_0RAhnfs5cvA@mail.gmail.com>
In-Reply-To: <20121125024451.1ADD14065F@snark.thyrsus.com>

On Sun, Nov 25, 2012 at 3:44 AM, Eric S. Raymond <esr@thyrsus.com> wrote:

> git presently contains one Python extension command, Pete Wycoff's p4
> importer.  If my git-weave code is merged it will acquire another.
> I think we can expect more submissions of Python extensions in the
> future, for two good reasons:

According to the Git User Survey 2012, 1% of the responders used the 'git p4' tool. I don't know how much widely used 'git weave' would be, but I wouldn't want to star changing policies for issues that are practically non-existent or irrelevant for the vast majority of git users.

Show 5 quoted lines

> We're behind the best-practices curve here.  The major Linux
> distributions, which have to deal with almost the same set of
> tradeoffs we do, went to Python for pretty much all glue and
> administration scripts outside /etc a decade ago, and the decision has
> served them well.

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.

> I should also point out that none of Mercurial's problems seem to
> have anything to do with the fact that it's written in Python...

I agree that the _current_ major problems with mercurial are not related to python, but once those are solved, who says python won't be an issue?. That's an exercise in guesswork, because we can't know.

Show 8 quoted lines

> I think we can choose a better policy based on some simple premises.
>
> 1) In 2012, we can specify a "floor" Python version of 2.6 (shipped in
> 2008) and be pretty much guaranteed it will be anywhere we want to
> deploy except Windows.  Windows will remain a problem because Python
> isn't part of the stock install, but that's an equal or worse problem
> for shell and Perl - and at least the Python project ships a binary
> installer for Windows.

What if my extension only supports python 2.7? Or what if my extension wants to support 2.0?

> 2) Python extension commands should test the Python version on startup
> and die loudly but gracefully in the rare case that they don't find
> what they need.

Yes, they should _if_ they know what version they need. In my extensions I really have no idea.

> 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, and I find it very chauvinist of you to say "python is better, so let's all use python". So far you have listed a few advantages of python, but you haven't explained so far what is wrong with shell and perl.

In fact, while advancing python you have made clear a problem with python; the version requirements. So far I have *never* encountered a problem with git because of my bash version, or my perl version. And we haven't touched to the python3 mess yet. To me, those are advantages of shell and perl.

Actually, I don't care if 'git foo' is written in perl, or shell, or c; as long as it *works*. And I would hate it if 'git rebase' ever told me that I need a newer version of python, or worst; that I don't have python in my system (Arch Linux ships 'python2', not 'python').

And what if X developer that wrote Y tool loves perl, and hates python? Or loves ruby? Are we going to kick him out of the project because (s)he refuses to switch to python? Are we going to threat him like an outsider, a rogue developer?

Show 6 quoted lines

> 4) We should be encouraging C code to move to Python, too.  There's
> little gain in portability on this path because modern C has cleaned
> up its act a lot, but the drop in expected bug loads would be well
> worth the porting effort.  Segfaults are not your friend, and the x2 to
> x5 drop in line count would do very good things for long-term
> maintainability.

Definitely NO! I really really doubt git in python would be able to achieve the same performance as git in c, but to show me wrong, it wouldn't be very difficult to run a few measurements with python dulwich *if* we are even to begin considering this point.

And are segmentation faults really that different from python's exceptions? Not to the user.

And why not ruby instead?

If you are serious about this, I think there's a lot more to work to show that there's anything wrong with the current situation, and that other alternatives (e.g. ruby) are not good solutions. I for one would like to see more tools move away from perl/shell, and into C. And other tools move to ruby, but that it's up to the developers of those tools, unless I myself do it.

Cheers.

-- 
Felipe Contreras