RAD with Python

Paul Winkler stuff at slinkp.com
Tue Sep 16 17:25:16 EDT 2003


vivek at cs.unipune.ernet.in wrote in message news:<mailman.1063374595.21980.python-list at python.org>...
> On Fri, Sep 12, 2003 at 06:09:02AM -0700, Ubaidullah Nubar wrote:
(snip)
> > 4. What types of applications are not suitable to be written in
> > Python?
> > 
> 
> System side softwares

I don't know what "system side softwares" means...

The one real drawback that comes up a lot when discussing python is
speed, since it's quite a lot slower than C.

Usually that's actually not a problem. When speed matters, good
results can be had by A) profiling and fixing your algorithms, B)
using psyco, C) replacing slow pure-python stuff with third-party C
extensions, D) replacing any remaining slow pure-python slow stuff
with your own C extensions.

However, there is at least one case when that's not likely to be
enough. An application that has critical realtime deadlines should
probably not have the python interpreter running in the realtime part.
 Example, realtime DSP. Say you're processing audio in a live
performance setting. If the interpreter decides to do a bunch of
garbage collection or otherwise slows down for a moment, you could
easily miss a deadline and get very nasty dropouts in the output.

Even in this case, python can be a useful part of the application as
long as the interpreter is kept away from the time-sensitive parts of
the app.
Here's a REALLY cool project with a C DSP engine controlled by the
movement of physical objects whose movements are detected and refleted
by a Python / OpenGL UI:
http://web.media.mit.edu/~jpatten/newaudiopad.html




More information about the Python-list mailing list