Why not a Python compiler?

josephoswald+gg@gmail.com josephoswald at gmail.com
Thu Feb 7 10:51:57 EST 2008


On Feb 7, 9:06 am, Steve Holden <st... at holdenweb.com> wrote:
> Ryszard Szopa wrote:
> > On Feb 5, 9:30 am, cokofree... at gmail.com wrote:
>
> >> I don't know the exact details but I think the issue is the dynamic
> >> nature of Python makes it impossible to correctly store the various
> >> types and changes into compiled code. Someone else will probably be
> >> able to provide a good reason as to why it isn't very feasible, nor a
> >> good idea. If you want to speed up your python look at Psyco.http://psyco.sourceforge.net/
>
> > Yeah, but exactly what features make it so hard to write a compiler
> > for Python?
> > [...]
>
> a. People tell me writing a compiler for Python is hard.
>
> b. It's certainly way to hard for me.
>
> c. But hey, I've heard about this neat language called Common Lisp that
> has a compiler. It looks a lot like Python.
>
> d. So why can't you brainboxes write a compiler for Python?
>
> Please tell me if I'm missing anything from this summary of your thought
> processes.
>

The basic difference is in point c. Common Lisp was a standard arrived
at by discussions including people who spent the 1970s and 1980s
developing high-performance native-code Lisp compilers targeting
conventional architectures (e.g. PDP-10, VAX, Sun workstations, etc.).
Stuff that would be hard to support with compiled code on conventional
CPUs was discouraged by the process.

The semantics of the Common Lisp standard were developed with the
needs of compilers in mind. CLOS is a very powerful object system, but
the design was developed with compilation and efficiency concerns in
mind. One major difference from Python OOP (as I understand it): CLOS
methods are looked up by their global method name. Python methods
(IIRC) are looked up in per-instance dictionaries. Redefining CLOS
methods requires changing one method-dispatch cache, and is supported
through a high-level interface, which a compiler can translate into
the low-level implementation machinery. Python code can mash the
dictionaries at will, because the low-level machinery is exposed.

The details, if I have mis-stated them, are not as important as the
principle of original design intent I am trying to illustrate.




More information about the Python-list mailing list