There are a number of design decision in python language that makes it inherently hard to write a fast python implementation.

There are lots of languages where variables are dynamically typed that can be compiled and optimized with a JIT compiler. In Python, though, any code can mess with any data, using "setattr". You can find all the variables in another module and mess with them at run time, using their names as strings. At compile time, the compiler can't detect that's going to happen.

This is sometimes called the Guido von Rossum Memorial Boat Anchor.

So Python implementations usually have to assume the worst case. Google's attempt at a faster, compatible Python, "Unladen Swallow", was an embarrassing failure. PyPy manages to get past that, but at a huge cost in JIT compiler complexity. After 12 years of work, PyPy is finally shipping stable versions and starting to get some use. It's been all uphill for the PyPy developers, though.

It's kind of sad. Python never achieved its full potential because of the speed problem. Google ended up developing Go because Python was too slow.

Python provides significantly more hooks into the behaviour of arbitrary objects, and arguably provides more flexibility than JS.

Here are a few notes from Mike Pall (LuaJIT) on Python features making a straight interpreter slower, and the language harder to optimise (JIT tightly): http://lua-users.org/lists/lua-l/2004-11/msg00083.html

Animats is full of shit, the ability to add arbitrary "static" attributes to existing objects is really not the main problem.

However certain language features can be inherently difficult to optimize. Most of it's over my head, but headius has written some great articles as part of his experience of implementing ruby on the jvm. http://blog.headius.com/2012/09/avoiding-hash-lookups-in-rub...