A faster Python?

[Paul Rubin]

Scott Hennesy <henne021 at tc.umn.edu> writes:
> For what I do, 90% of the time Python is fast enough. But for that
> 10% of the time I find myself wishing for a faster Python.
> 
> What's the consensus out there? Do Psyco, NumPy, and SciPy fulfill
> the need for speed or is there a desire for a faster Python?

NumPy and SciPy are just for numerical computations, but they're
indispensible in those areas.

Psyco is a research project.  It would be great if it were developed
further, but in its current form it's not really useful.

> If so, what are the requirements for a faster Python? How much
> faster does it have to be? How much compatibility does it need with
> Python? How much resources can be devoted to optimization? Easy
> example: 20% faster, no compatibility, infinite resources. Hard
> example: Faster than optimized C, total compatibility, no resources
> ;-)

If you can get a 20% improvement without a lot of effort, go for it.
I think really big speedups will require a new compiler/interpreter
implementation (lots of work) and some changes to the language.

I don't think Python can be made to run faster than optimized C, but I
think it should evolve towards being able to run as fast as compiled
Lisp or Scheme.  

> I've considered doing something about maybe a half dozen
> times. Maybe with Python 2.2 the time is ripe?

2.2 isn't the time for sweeping changes but the issues should be kept
in mind constantly.  For now, I'd say it's a problem that the language
definition is so closely bound up with details of the CPython
implementation.  All the hacks like representing instance variables in
a __dict__ dictionary, or the particular layout of stack frame
objects, should be documented as specifics of a particular
implementation rather than as how the language works (this goes for
most everything surrounded by double underscores except for class
methods like __init__).  This is mostly a matter of how the
documentation is written, not the code.

If a new implementation gives much better performance (like a 5-10x
speedup, which I think is realizable) and stays reasonably compatible
for normal applications, but requires big changes in some low level
tools like debuggers, I think that's ok.

For now, there may not be the resources to implement such a thing, but
it's appropriate to begin paving the way for it to happen someday, by
trying not to add too many implementation-specific requirements to
the language definition.