The short answer is you don't really have limits. Unless you're doing something slow / inefficient, that would be slow anway. Brute forcing / re-creating surface every frame / mixing different formats on your surfaces / etc.
Biggest one I'd think is collision detection. You can make your algorithm more efficient / use quadtrees / or probably use a physics module. Depending on the game, that can be overkill. == But remember, 'premature optimization, is the root of all evil'. And when you optimize, use profiling. Because 99% of the slowdown can be in 1% of the code. And you will rarely know where it is, without profiling. This can be true even in simpler code. == If you do reach a slowdown, there's a huge amount of modules that you have access to. That causes the slower code to run c-code, and has been optimized by many people ie: PyOpenGL, pybox2d (physics), numpy (for arrays / 3d math / opengl), pygame, etc... So between optimizing your algorithms ( That you'd have to do in other languages anyway: Not re-allocating textures every frame, or other errors ), using c-code from other libraries, You don't run into much different speed issues than you do in pure c, for most games you'd work on. -- Jake
