Python execution speed

[Morten W. Petersen]

On Mon, 19 Nov 2001, Peter Hansen wrote:

> Fernando Pérez wrote:
> > 
> > > I'm curious, however, why you believe you need to optimize Python's
> > > execution speed so much?  Do you have some application which is not
> > > performing adequately?  The usual approach is simply to profile the
> > > code and recode the "hot spot" in C.
> > 
> > I can mention one: scientific computing. Python is becoming very popular in
> > that field, and Numeric goes a long way.  But sometimes it's not enough, and
> > being saved from dropping down to C for anything but the truly ugliest would
> > be a big blessing. And yes, in scientific computing, things are *never* fast
> > enough. If you can improve the speed of a code even by a factor of 2 only,
> > that can be big news. Waiting for 2 days is still better than waiting for 4
> > days for your simulation to finish.
> 
> I understand these issues, but I really wanted to know why the *OP*
> thought he needed more speed (which I inferred was the only serious 
> advantage he felt he'd found with LISP over Python).

It's one of the advantages I see, if true.  Another is macros (which I
don't fully understand the scope of yet).

There's an underlying question here though, and that is how fast is the
Python community able to adapt and implement good ideas.

One of Python's advantages is a consistent (simple) design, (not counting
small quirks like 'def function(): return 1' and 'function =  
lambda: 1'.  Consistent design says 'less complexity' in my ears, along
the same lines of the simpleness (ease of maintenance, readability,
portability) of a python application if it can always be coded in Python.

Regards,

Morten