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:

1. Python has a much richer type ontology than shell; there are many
things this makes relatively easy that are quite painful in shell.

2. While Perl shares advantage #1, compared to Python it's a
maintainability mess - much more difficult to read 6 months later.

On the other hand, 

3. Attitudes in the git dev group seem to be influenced by a
perception that up-to-date Python versions are not as reliably present
on our target platforms as Perl is.

4. Python has the disadvantage that comes with robust growth; you have
to specify "version x.y or later" as a dependency, mainly because new
modules keep getting getting folded into the stock Python environment.

Previous conversation on the list suggests that there has been a tacit
policy of managing these problems by (a) discouraging (though not entirely
forbidding) Python extensions, and (b) requiring extension submitters to
document some dependency on language version.

I think this is suboptimal.  By not forbidding the Python language
entirely, we guarantee having to deal with problems 3 and 4 anyway -
but by discouraging it, we're buying significant long-term
maintainability costs. It especially disturbed me to hear of Python
commands being recoded in C - that is definitely not the right
direction for reducing expected defect counts, if only because of
memory-management issues.

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.

That, among other things, means up-to-date versions of Python are
ubiquitous unless we're looking at Windows - in which case Perl and
shell actually become much bigger portability problems.  Mac OS X 
has kept up to date, too; Lion shipped 2.7.1 and that was a major
release back at this point.

To be fair, there was a time when being a bit twitchy about Python
version skew and deployment breadth was justified, but I believe that
time is now well past us. My basis for believing this is very simple -
I maintain a lot of Python code for systems programmers with stiff
portability requirements (things like reposurgeon, coverity-submit,
freecode-submit, shipper, and the Python tools in gpsd). I know what
kinds of bug reports I get and what kinds I don't, and in the last
few years "this breaks on my Python version" has gone from unusual
to doesn't-happen.

I think my experience with gpsd is particularly instructive.  Like
git, that project has a C core with Python wrappers and extension 
components. Like git, it gets deployed in a lot of odd places by people
who cannot afford the time to be tolerant about cross-platform
problems and are quite willing to hit the maintainer with a clue-bat
when they encounter them.  The good news is - they don't have to.

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 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.

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.

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.

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
                <a href="";>Eric S. Raymond</a>

Live free or die; death is not the worst of evils.
        -- General George Stark.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to