Why doesn't Python have these?
I'm not sure why you think there are no Python implementations that care about performance. PyPy, IronPython, and Jython are all industrial-strength, production-ready Python implementations which care about performance. Pyston is an in-development implementation that was specifically created for performance. Unladen Swallow and Psyco were also projects to improve the performance of Python.
However, the fact that CPython users greatly outnumber the total combined user base of all the other implementations, that Unladen Swallow was rejected by the community, that most of these projects are either dead or struggling to attract developers should tell you something about how the Python community values performance.
This answer is a good example of the typical mentality of the Python community: instead of fixing the performance problems, they would simply prefer to write their code not in Python.
I have been looking at PyPy and IronPython, which both claim speed gains. PyPy I don't understand how a Python implementation written in Python, an interpreted language, will be faster than the reference implementation in C.
First off: it doesn't matter which language the compiler is written in. After all, the compiler is only executed once, so even if it were slow, that doesn't matter: the performance of the compiler is irrelevant, what is relevant is the performance of the output of the compiler.
Secondly, since it only matters how fast the output of the compiler is, and the compiler is written in Python, i.e. the language that it compiles, it can actually make itself fast by compiling itself.
Thirdly, there is no such thing as an "interpreted language". A language is a set of mathematical rules and restrictions. It is a specification. A piece of paper. A language isn't compiled or interpreted. A language just is. Compilation and interpretation are traits of a language implementation, more precisely, a compiler or interpreter (duh!), not the language. Every language can be implemented by a compiler. Every language can be implemented by an interpreter. You can mechanically generate a compiler from an interpreter and an interpreter from a compiler.
But all of this doesn't actually really matter, because PyPy is actually not written in Python. It is written in RPython. RPython consists of two parts, the RPython programming language and the RPython framework.
The RPython programming language is not Python. It is a different programming language. RPython is a statically-typed programming language, roughly on the same level on abstraction as Java, with roughly the same performance as C. RPython is a syntactic and semantic subset of Python, which means that every RPython program is a valid Python program and can be run by a Python implementation (albeit typically several orders of magnitude slower, but this is still useful for debugging because you get access to all of Python's tools, and interpretation starts right away, whereas compiling the language implementation typically takes about 5-10 minutes), but the converse is not true.
The RPython framework is a framework for writing high-performance dynamic language implementations in the RPython programming language. It includes a garbage collector, object space, meta-object protocol, pre-defined objects, types, and operations, and so on. But the crown jewel is its ability to automatically generate a JIT compiler from an interpreter: if you implement a language in the RPython framework, you only have to write an interpreter, the RPython framework takes care of the JIT.
There are plenty of language implementations on the RPython platform, not just PyPy.
IronPython, same idea but I don't see how the .NET Framework will increase speed.
Most implementations of the ISO CLI, such as the various .NET variants by Microsoft, or Mono, contain sophisticated garbage collectors, optimizers, and compilers. The same is true for Jython and Java implementations.
IronPython is a compiler, it compiles Python source code to DLR trees (DLR is the Dynamic Language Runtime), which are then further compiled to CIL byte code, which is then again typically further compiled to native machine code.
