Towards faster Python implementations - theory

[Terry Reedy]

"sturlamolden" <sturlamolden at yahoo.no> wrote in message 
news:1178895563.144837.176310 at e65g2000hsc.googlegroups.com...
| On May 10, 4:02 pm, Tim Golden <m... at timgolden.me.uk> wrote:
| I know, I know. But that doesn't stop me from envying what the Lisp
| community has achieved.

But do not let your envy stop you from noticing and appreciating what the 
Python commnunity has achieved.

| Python still sucks if we are using it for scientific simulations,

Not if you use extensions compiled from C or Fortran.  Doing so is not 
cheating, any more than using the C-coded methods of the builtin types. 
Leveraging existing code and compilers was part of Python's design.

With the Numeric extensions, produced by people at the US nuke labs. 
scientific simulations were, I think, Python's first killer ap.

| Sure it is only 150-200 times slower than C for these tasks,

As a general statement, nonsense.  A LinPack inversion of a 10k x 10k 
matrix takes the same time whether called from Python or a C program.  The 
miniscule extra overhead of Python is more than made up for by the ability 
to call LinPack and other functions interactively.

The extended buffer protocol, championed by Travis Oliphant and slated for 
3.0, will make cooperation between extensions much easier.

Terry Jan Reedy