Hey im just posting this to get a feel for how people feel about Python being used as a standalone programming language as opposed to using it as a scripting language for certain portions of programs? Im mainly talking about 2d and 3d video games, but how do you feel about it being used as the sole language to program various different types of software? Is it powerful enough to do more than script?

Python wasn't designed as an extension language. In fact, when you try to use CPython for extension purposes, you run into a number of difficulties and inconveniences. The language was intended to serve as a standalone programming environment, extensible in C; that it is embeddable is a happy side effect.

In other words, yes, it is powerful enough to do more than script. There are all manner of libraries to provide extensive capabilities to Python, from multimedia libraries to full 3D engines.

Enjoy!

Thanks for the info.. So let me get an idea of its capabilities please. Lets say you knew both Python and C++ extensively. You then took an entirely C++ written sourcecode from a game like.. lets say.. half life 2. Now, If you had access to all the 3d models and maps and all that stuff, could you successfully rewrite the entire game in python? Im guessing you would have to of course use python ready APIs such as pyopengl instead of tools that are only made for C++ like DX or OpenGL. So is something like this possible? What would the outcome be? Im obviously not going to do this lol but its just an example to show me what its capable of.

I'm currently learning Python through building little apps - currently text-based games similar to roguelikes (I'll be posting about this in my journal as I go). I'm evaluating it to see how well it suits my purposes as a general programming language; if it works well I'm planning on moving mainly to Python. At the moment I'm more concerned with development time than how fast the program runs.

As Oluseyi wrote, Python is designed as a stand alone programming language with the capability of writing your own libraries in C. My general plan when I get to speed critical apps like games would be to build the thing in Python first, profile it to see where the bottlenecks are (the bits of code that are executed the most), and rewrite those bits in C. If you build your program like that, I could see your Python with C program being almost as fast as a pure C one, with the added benefit of being much easier to write.

Quote:Original post by biggjoee5790
What would the outcome be?

It would be marginally slower, but that's about it. The Senshi was telling me during GDC about his game that uses PyOpenGL and PyODE, and how it's surprisingly performant as well as flexible and robust - I thought there might be some slow downs with graphics operations, but he said that's not the case.

Ya I read a lot obout people writing in Python and using C to speed up certain portions.. im not concerned with that now anyways since I only know Python :) Also when you say it would be marginally slower, what do you mean by that? Like the game will run at low fps?

so if you use pyopengl and pyode, you dont need any C++ knowledge do you? Do you just have to learn how to access their functions through the python language instead of C++?

It would be helpful to know a little bit about C/C++ syntax because people don't typically rewrite the complete API documentation with Python in mind. At some point you'll probably have to read docs that give C++ examples of usage and work out for yourself how it should look in Python.

It's valuable to know C++. It will remain valuable to know C++ for a long time to come. However, it is not required to know C++ to create a reasonably complex, performant game.

Re marginally slower: some semantically equivalent operations in Python take a little bit longer to complete than their C++ counterparts because the Python version does more. This is due to the nature of the language - the biggest performance hit is in dynamic type resolution, which isn't used in the majority of Python statements but is insanely valuable when you do need it. A pretty cool project I discovered a while back is StarKiller, which removed the dynamism from objects that it can statically determine don't need it. Unfortunately it appears dormant since the 2004 PyCON presentation, and there's been no attempt at integrating it with any production distribution.

Anyway, the areas where this dynamism constitutes a relevant performance penalty are very few. Generally, doing the semantic equivalent in C++ requires more code, anyway, so using Python turns out not to be much slower in practice. What this means for your game is that you can do slightly less each frame - push a few less polygons, apply a few less effects - while maintaining the same frame rate (or, conversely, generate a few less frames per second). It likely won't be a bottleneck for you for quite a while, anyway, so don't worry about it.