first release of PyPy

[Paul Rubin]

Christian Tismer <tismer at stackless.com> writes:
> Type inference works fine for our implementation of Python,
> but it is in fact very limited for full-blown Python programs.
> Yoou cannot do much more than to try to generate effective code
> for the current situation that you see. But that's most often
> quite fine.

Type inference (or static type declarations) is one part of compiling
dynamic languages but I think its importance is overblown in these
Python compiler threads.  There's lots of compiled Lisp code out there
that's completely dynamic, with every operation dispatching on the
type tags in the Lisp objects.  Yes, the code runs slower than when
the compiler knows the type in advance, but it's still much faster
than interpreted code.

I'd expect one of the worst bottlenecks in Python is the multiple
levels of dictionary lookup needed when you say a.x().  The
interpreter has to search through the method dictionaries for class(a)
and all of its superclasses.  It has to do this every time you do the
operation, since those dictionaries can change at any time.  Being
able to do that, it seems to me, is NOT in the interest of reliable or
maintainable programming--look at the cruft in socket.py, for example.
Being able to statically generate the method call (like a C++ compiler
does) or even just being able to cache a method list in each class
(avoiding searching through all the superclasses on subsequent calls
to any operation) would probably make a big difference in execution
speed in both the compiler and interpreter.  It would require a change
to the Python language but I think the change would be a beneficial
one both from the software maintainability and the performance point
of view.