There is only one Python. This might come as a surprise to many people, so let's explain.
When BDFL started to develop Python, he was influenced by many ideas from other programming languages. Despite what you might think if you tried lazily thinking about some sexy aspects of it that are nice to tinker about, language design is hard. Not even BDFL gets it right every time. But differently from most other language creators, he's not afraid to say when that happens, and fix things.
Example: a long time ago, Python had int and long, two different types to represent the same thing (mathematical integers), just because one was "native" (fixed size, directly supported by underlying architecture) and thus fast, and another was correct. Of course, it's known that in programming, most integers are used as indices in small and moderate size arrays, where native type surely suffices.
But that's solving the wrong problem. Having a type that, because of its name among other things, suggests representation of counting numbers (and their opposites), but is unable to represent the number of humans currently alive, is just wrong. C has two strong reasons for sticking to that point of view (bare metal approach, and value semantics), neither of which has anything to do with Python. Its types are supposed to be representations of real-life concepts, not of processor and memory induced abstractions in another programming language. [Of course, if one models a behavior of some C program in Python, int32 would be a perfectly appropriate type. But that's surely too narrow for a built-in.]
Guido realized that, and since Python 3, there is only one int type, which chooses internal representation according to its size, and the whole model is hidden from the user pretty well. From the perspective of a programmer, 2**3 and 2**99 is calling the same method, int.__pow__ (it's even the same bound method, 2 .__pow__:), and the result has the same type as the operands. Of course it required some very deep interventions in the implementation and documentation, but BDFL boldly did it. There were many other such huge changes (Unicode, true div, delayed functionals,...), which were treated just as boldly.
How could he be so bold? It's really simple: there is such a thing as ideal Python implementation. All real implementations are just shadows of that Platonic idea, and although we can't always intuit the real idea from the shadow a priori, the thing works really well a posteriori: once you see the true thing, it's obvious.
So, Python 3.4 (or whatever it is in the moment you read this) is the most accurate existing approximation of true Python, which is the real subject of this blog. People usually ask me why do I hate Python2... I don't hate it. The same way I don't hate Newtonian mechanics -- it's wonderfully useful, up to a few warts here and there. But it isn't deeply, really the way the Universe works. Of course, neither is General Relativity (and neither is Python3) -- it's just that it's the best thing we've got. And it's pretty damn good.