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 maintainability. -- <a href="http://www.catb.org/~esr/";>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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html