A better self

[Michael Chermside]

Michael Chermside wrote:
         ...
> shouldn't be using Python. Yes, Python is a nice language, and yes, it
> can be sped up by recoding key portions of an application in C/C++, but
> it is never going to be as fast as an algorithm hand coded in assembly.

Alex Martelli replies:
> It may happen to be just as fast (that would be a rare coincidence)
> and it may well be (more likely:-) *much faster*.
>
> That's because more often than not you won't be coding the SAME
> algorithm in Python or assembly.
         ...

Alex is (of course) completely correct. My true point was that Python 
and a mindset of "do whatever you can to save an extra CPU cycle" don't 
fit well together. But Python can be MUCH faster, in a lot of cases.

I'll give an example.

     #
     # A program to sort lines. Takes, as command-line argument, a
     # filename (the file will contain one word or phrase per line),
     # and outputs the sorted file to stdout.
     #
     import sys
     filename = sys.argv[1]
     lines = file(filename).readlines()
     lines.sort()
     for line in lines:
         print line

Except for some pretty strange circumstances (extremely large file, OS 
with really bad virtual memory), this is going to be faster than the 
equivalent C program. Unlike the C program, it has to set up the 
interpretor, do interpretation of the Python bytecodes, allocation and 
reference counting of Python objects, and use OS portable file reading. 
But all of these are dwarfed (for large file sizes... let's say 1 GB of 
text) by the fact that you are running a REALLY FAST sort algorithm.

Of course, you could code the same sort algorithm in C yourself. Heck, 
for that matter, you could copy the sort algorithm (written in C) from 
the C source to Python (Python's liscense allows that!). But you 
wouldn't. Really... you wouldn't.

But this is all beside the point. The **REAL** reason to use Python for 
a problem like this is that the Python script is only 6 lines long, and 
those lines are so elegant, so easy to understand, that a computer savy 
*middle school student* could understand them, maintain them, and 
perhaps even write them. The equivalent C progam would be much, much longer.

Yes, there are times when Python is faster... and usually it's because a 
different (better!) algorithm is used (eg: use dicts instead of linear 
search through a list). But where it REALLY shines is in its clarity. 
And that clarity lets you think at a higher level (notice how I never 
had to stop to think about memory allocation or max line lengths?). And 
THAT lets you write better programs.

-- Michael Chermside