Why I love python.

[Nick Patavalis]

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? 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?

>
> 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). Most of this way has to do with Python
*implementations* and not with Python-the-Language. But it seems that
there are some steps that must be taken by the language itself in
order to open the road to efficient implementations.

/npat