Python future performance and speed

[Tim Churches]

On Tue, 2004-08-24 at 03:58, Aahz wrote:

> That's true.  If that's what you'd said in the first place, nobody would
> have argued with you.  However, this is what you said:
> 
>     It seems there are quite a few projects aimed to improve Python's
>     speed and, therefore, eliminate its main limitation for mainstream
>     acceptance.

Hey, cut the boy/girl some slack. I suspect what s/he meant to say was:

     It seems there are quite a few projects aimed to improve Python's
     speed and, therefore, eliminate its main perceived limitation for
     mainstream acceptance.

I think you'll find it much harder to take issue with that statement. I
can only offer anecdotal evidence, but a typical conversation about our
Python-based projects goes like this (where the conversant typically
thinks that there are only two viable languages for any software project
these days: C# or Java):

a: "What language are you using?"
b: "Python"
a: "Um, isn't that too slow?"
b: "In general, no, and anyway there is a thing which is a bit like a
JIT compiler available, and for the really speed-critical parts, you can
use C modules very easily."
a: "Oh, OK, sound complex."
b: "No, it's not, really, and Python is really fast to write."
a: "But I have to write all those C modules."
b: "No, hardly ever, really."

And so on. The **perceived** speed of Python is indeed a barrier to its
acceptance, and indignant posts on this list won't do much to dispel
that perception. More published case studies and benchmarks of Python
versus whatever else when used for **complex**, real-life problems, not
artificially simple looping benchmarks, would help.

-- 

Tim C

PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere
or at http://members.optushome.com.au/tchur/pubkey.asc
Key fingerprint = 8C22 BF76 33BA B3B5 1D5B  EB37 7891 46A9 EAF9 93D0