merits of Lisp vs Python

greg greg at cosc.canterbury.ac.nz
Mon Dec 11 22:35:48 EST 2006


Bill Atkins wrote:
> greg <greg at cosc.canterbury.ac.nz> writes:
> 
> > There's no way you could compile Python to efficient
> > machine code just by macro expansion. You'd also need
> > some very heavy-duty type inferencing.
> 
> A compiler shifts a lot of decisions that an
> interpreter would have to make at runtime to compile-time.  There is
> no reason a dynamic language can't enjoy this efficiency.

I'm not saying that it's impossible to compile
Python, only that's there's a lot more to it than
just macro expansion. The OP was saying something
like "If you added macros, you might get a compiler
for free", which is clearly far from true.

> if Python is doing a hash lookup on every function call,
> as Alex Mizrahi claims, compilation may not do much to smooth over
> such awkwardness.

As currently implemented, CPython does a dictionary
lookup or two every time a module global or builtin
(which most stand-alone functions are) is referenced.
It would actually be relatively easy to optimise this
into an array lookup in most cases, but most calls in
Python code tend to be *method* calls, which are rather
harder to deal with. Possibly cacheing of method
lookups would help, although I don't know of anyone
having tried it.

> > Python is extremely dynamic, even more so than Lisp.
> 
> Uh huh.  "More so than Lisp"?  Just making stuff up now?

When a Lisp compiler sees

   (setq c (+ a b))

it can reasonably infer that the + is the built-in numeric
addition operator. But a Python compiler seeing

   c = a + b

can't tell *anything* about what the + means without
knowing the types of a and b. They might be numbers, or
strings, or lists, or some user-defined class with its
own definition of addition.

 From another angle, think about what a hypothetical
Python-to-Lisp translator would have to do. It couldn't
just translate "a + b" into "(+ a b)". It would have
to be something like "(*python-add* a b)" where
*python-add* is some support function doing all the
dynamic dispatching that the Python interpreter would
have done.

That's what I mean by Python being more dynamic than
Lisp.

> Despite its dynamism, Lisp is quite compilable.

Please correct me if I'm wrong, but as I understand,
getting efficient code out of a Lisp compiler requires
putting type declarations into the source.

If you put the same declarations into a piece of
Python code, then of course it would be fairly
straightforward to compile it efficiently. But it
wouldn't really be dynamic Python any more.

Python may end up going this way -- there are
currently plans to make room for attaching optional
annotations to function arguments, which could be
used to convey type information to a compiler
(although that's not currently the main intended
use).

The alternative is whole-program analysis and huge
amounts of type inferencing, which the PyPy people
are working on. Maybe something practical will come
out of that.

Whichever, it's nowhere near a simple as just
"adding macros"!

--
Greg



More information about the Python-list mailing list