Why I love python.
dave at pythonapocrypha.com
Fri Aug 13 16:44:14 CEST 2004
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,
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
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
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,
Costs: use CPU cycles that were already idle anyway
More information about the Python-list