Why is this loop heavy code so slow in Python? Possible Project Euler spoilers

[Paul Rubin]

Steven D'Aprano <steve at REMOVE-THIS-cybersource.com.au> writes: A big
> question mark in my mind is Lisp, which according to aficionados is
> just as dynamic as Python, but has native compilers that generate
> code running as fast as highly optimized C. I'm not qualified to
> judge whether the lessons learnt from Lisp can be applied to Python,
> but in any case Lisp is an old, old language -- only Fortran is
> older. The amount of development effort and money put into Lisp
> dwarfs that put into Python by possibly a hundred or more.

Writing a simple Lisp compiler is not all that difficult.  There's a
chapter in SICP about how to do it, so it's sometimes part of
introductory courses.  To get C-like performance you end up having to
rely on user-supplied type declarations and/or type inference, but
even without that you can still do ok.  I'd say Lisp is a less dynamic
language than Python.  Lisp doesn't have duck typing and doesn't
represent class instance variables as dictionary elements that have to
be looked up at runtime all the time.  This maybe even applies to
locals, e.g. in Python if you say

   x = 3
   print "hello"
   y = x + 4

you're possibly not guaranteed that y=7, because you might have bound
sys.stdout to something with a .write method that reaches up the call
stack and messes with the caller's local variables, and if the langref
manual says this is supposed to work, then the compiler has to do it
like CPython.  Maybe Python 4.0 will fix some of this stuff.