Why I love python.

[Dave Brueck]

Nick Patavalis wrote:

> On 2004-08-13, Anthony Baxter <anthonybaxter at gmail.com> wrote:
> 
>>I'm biased, having done a paper on this at the most recent PyCon, but
>>I firmly believe that much of the "Python is too slow" arguments can be
>>answered with "too slow for what?" See the pycon proceedings, but I've
>>been doing VoIP in Python, complete with audio mixing, and it's been 
>>more than fast enough. 
>>
> 
> Yes but what parts of it were done in python, and what parts were done
> inside modules written in C?
> 
> Do you believe, for example, that a web-server written in python could
> outperform apache?

Yes. Apache is not that fast, and web servers are often more network 
bound than CPU bound.

 > How about an H323 implementation, or a TCP/IP
> stack? Or a font renderer? Or a ray-tracer? A gate-level circuit
> simulator? A web-browser? A relational database?

Nobody is arguing that Python is as fast as C. But being slower does not 
imply that Python is unsuitable for those tasks. I'd consider your list 
to be pretty atypical of normal development (how many TCP stacks and 
relational databases need to get written each year?), but even so most 
of the items on your above list _have_ been done in Python and have done 
pretty well for a number of applications. I'd wager that the vast 
majority of programs written have at their disposal more CPU than they 
need, so using more of that spare CPU power (by using a higher level 
language like Python) is a cost many people are ready to pay for many, 
many applications.

Note also that all or most of those programs on your last at one time 
had to be partially implemented in assembly language even if the main 
language was C or C++, and yet that didn't make C or C++ unsuitable 
development languages for the task (nor did it make them only "glue 
languages"). The same can hold true for Python in many cases - if a 
small portion needs to be developed in a lower-level language you can 
still derive great benefit from doing the rest of the application in 
Python.

In nearly all of the cases where I was sure I'd have to later recode a 
portion in C for performance, that day never arrived. For some reason 
additional performance is always welcome, but the lack thereof rarely 
ends up becoming a big deal. (And this is not just in my own projects - 
when other people/companies are driving the requirements they are pretty 
much always more interested in getting it to market and adding new 
features. On one project in particular I have on my todo list to go 
rewrite the performance "critical" core in C and it's been on my todo 
list for a couple of _years_ now because I'm the only one left who cares 
that it could be faster - everyone else is focused on feature set. And 
since the core is partially CPU bound its performance has more than 
doubled during that time due to faster CPUs - here I am sitting still 
and the problem is going away :) ).

>>Sure, you're not going to get great performance for your numerical
>>computation in Python, but luckily, we have numarray for this. 
>>
> If numarray was written *in Python* I would be delighted. But even
> with numarray, if you want to do FFT, you do it in C, not in
> Python. And if FFT is not good for you and you need DCT, again in
> C. And if the FFT of numarray is not sufficient (e.g. you want an
> integer version with certain bit-exact properties), hmmm sory, you
> have to do it in C.
> 
> At this moment Python is an excelent *glue* language for stuff written
> in low-level laguages. It is also an exelent prototyping language. It
> has a long way to go before becomming a true "production" language (in
> the sense outlined above).

I have to disagree - we use it as our main production language for so 
many different things it's hard for me to sit still when it's 
pigeonholed as just a glue language (*especially* when a lot of our 
Python programs sit idle for large blocks of time waiting for e.g. the 
database to get done or for the network pipe to become less saturated).

Maybe it all comes down to domain, but for me the cases you describe are 
rare and oddball enough that if a little C is needed to get the job done 
then it's no big deal because they make up such a tiny minority of all 
the problems we're solving.

C/C++ are becoming less and less suitable for production use - their 
main remaining advantage is performance and that becomes a smaller and 
smaller issue each year. Everything from manual memory management to 
hacky, primitive data structures (even _with_ C++/STL) make them more of 
a liability than an asset - development in them is slow, error-prone, 
and therefore too expensive. For personal projects I don't have enough 
spare time to waste it coding in something so low-level as C, and for 
professional projects the raw speed is generally valued but much less so 
than time-to-market and cost of change so I can't justify C/C++/etc 
there either.

99% of the time the tradeoff for using Python comes down to this:

Benefits: low cost, fast time to market, cheap addition of new features, 
fewer bugs

Costs: use CPU cycles that were already idle anyway

Score!

-Dave