Kay Schluehr wrote: > Indeed. The only serious problem from an acceptance point of view is > that Mark tried to solve the more difficult problem first and hung on > it. Instead of integrating a translator/compiler early with CPython, > doing some factorization of Python module code into compilable and > interpretable functions ( which can be quite rudimentary at first ) > together with some automatically generated glue code and *always have > a running system* with monotone benefit for all Python code he seemed > to stem an impossible task, namely translating the whole Python to C++ > and created therefore a "lesser Python".
Trying to incrementally convert an old interpreter into a compiler is probably not going to work. > Otherwise it > wouldn't be a big deal to do what is necessary here and even extend > the system with perspective on Py3K annotations or other means to ship > typed Python code into the compiler. Shed Skin may be demonstrating that "annotations" are unnecessary cruft and need not be added to Python. Automatic type inference may be sufficient to get good performance. The Py3K annotation model is to some extent a repeat of the old Visual Basic model. Visual Basic started as an interpreter with one default type, which is now called Variant, and later added the usual types, Integer, String, Boolean, etc., which were then manually declared. That's where Py3K is going. Shed Skin may be able to do that job automatically, which is a step forward and more compatible with existing code. Doing more at compile time means doing less work at run time, where it matters. This looks promising. John Nagle -- http://mail.python.org/mailman/listinfo/python-list