Christian Tismer <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
