On May 22, 1:49 pm, Terry Reedy <tjre...@udel.edu> wrote: > Because, as I said, and as you explain further, Python favors programmer > speed, including speed of testing new algorithms, over raw execution > speed of current algorithms. (Current) speed is (also) easier to test > than improvability and hence possible speed improvements.
First of all, I don't think you and Lie have any basic disagreements. The key realization is that the quantitative difference in programmer speed you mention is so large (orders of magnitude) that, for many classes of problems, it is not just *possible*, but actually *probable*, that a Python implementation *will be faster* than a C implementation. Yes, you are absolutely correct that most Python programs can be made faster by adding a bit of C, but that doesn't negate the fact that if I can throw 'x' man-hours at a problem, for lots of real-world values of 'x' and of 'the problem', a pure Python implementation will run rings around a pure C implementation, assuming the C implementation even works by the time I've burned through 'x' hours. I discussed this a bit on this newsgroup over five years ago, and the points are still pertinent: http://groups.google.com/group/comp.lang.python/msg/910a54ddec946567 > If and when mercurial deveopment slows down, some of its developers > might consider whether any of the utility functions written in Python > might usefully be rewritten in C. One of the intentional virtues of > Python is that one can transparently convert part or all of a module > *without changing* the import and use of the module. I don't even think that Mercurial development has to slow down to decide to recode a few things in C. A tiny bit of C at the right place can often provide more than enough leverage to be worthwhile, and be small enough to throw away if need be. Regards, Pat -- http://mail.python.org/mailman/listinfo/python-list
