[Tutor] Is Python the language for me?

[Luke Paireepinart]

Andy wrote:
> Hey everyone, I'm looking to get the opinions of some people with more
> experience then myself.  Currently I only have time to learn one
> language and I'm torn between C++ and Python.  Eventually I would like
> to make a game, nothing too extravagant, a turn based strategy game to
> be exact.  I'm not planning on having crazy graphics effects, I'm
> going to focus on game play.  Anyway, I'm getting a little off course
> here.  I want to learn one of the two mentioned languages with the end
> goal to be able to make my game.  I know it's a long way off before
> I'll be able to make it so please don't assume that I'm going to jump
> right in expecting to make this in a matter of months.  Besides the
> game, I have all kinds of ideas for small little programs that I would
> like to make.
>   
Sound like reasonable goals to me :)
> I would honestly rather use Python then C++ but I have a few concerns.
>  How hard is it to manage a large project in Python vs. C++?
I have found things that would be a 'large project' in C++ often aren't 
nearly as large in Python.
I think if you have a large project in Python, the equivalent project in 
C++ would be much harder to manage.
you can use packages and such to keep your code manageable.  It's 
probably a good idea to keep your code separated
from the get-go when you reach the time to make your game, because it'll 
eventually get to the point where you'll need to break it apart,
so you'd be doing yourself a favor.
>   If I do decide to use Python I would be using Pygame for the graphics end of
> things.  From what I can tell, Pygame does not work with the current
> release of Python, that's one of the things that causes me to worry.
> If I finish this game and release it, are people going to constantly
> be having to upgrade Python and Pygame for it to keep working?  And
> how much really changes between releases?
>
> Python has built in access to a windowing toolkit (Tkinter), C++ can
> of course use the native windows/linux/mac API but that seems like
> more of a hassle to me.  Once the C++ program has been compiled it's
> much easier to distribute.  C++ has a much higher learning curve and
> development time then Python does.  Python has a much nicer community
> built around it then C++ from what I can see though.
>   
Okay, first thing to note:  a lot of Python developers prefer wxPython 
to Tkinter.
There is an equivalent library in C++, since wxPython is really just a 
light wrapper around wxWindows.
There's a big community around that project, and I doubt it would be too 
much harder to learn wxWindows vs wxPython.
(Trying not to sound too biased toward Python :) )

Now to address your concern about Python and Pygame:
If your program works with a certain version of Python and Pygame,
say  Python 2.4.4 and pygame 1.7,
it will continue to work for Python 2.x.  Python versions maintain 
backward compatibility very well,
but in Python 3000, they're going to break backward compatibility.
I believe the same is the case in Pygame versions (unless they make the 
1.8 release use NumPy instead of Numeric,
which would require a few changes to some people's code, likely only a 
line or two.)
So once you write your game, people will be able to upgrade and it will 
continue working.
But there's no reason for them to upgrade unless they need the new 
features of the new versions.

Also, something that should really ease your concerns:
You can create .exes with Python that will contain a static instance of 
whatever modules you had installed
at the point when you run py2exe (or some other packaging program) that 
are used in your game.
So if you use Numeric version 2.55 and Python 2.4.3 and Pygame 1.7, then 
those versions of the packages
will be included in a file you can distribute.  Well, it's not a single 
file, but a zipped collection of files.
In that case, people don't even need Python installed on their computer 
to run your game!
It also doesn't interfere with any Python versions they may have 
installed on their computer.

So in that case you don't have to worry at all about people upgrading 
libraries, just like you wouldn't if you were to make
a binary in C++.
> So as you can see I feel that each language has it's own pro's and
> con's and I might end up learning them both eventually.  Do you all
> think Python will work for what I want right now?  My biggest concern
> with Python is the upkeep involved in trying to distribute your
> applications.  Do updates to Python usually cause issues?  Why would
> something like Pygame work with Python 2.4 but not 2.5?
>   
As an introductory language to Computer Science I'd recommend Python.
You spend less time trying to understand the language itself and more 
time learning abstract concepts like
how a merge sort works, inheritance, classes, 'self', and things like that.
Once you understand all of these things, C++ will be greatly easier to 
pick up, as should most Object-Oriented languages be.
I think if you start with C++, you'll get discouraged.
Perhaps not, but that's how it worked with me.

A few years ago, I tried to learn C++, and I failed miserably.
Then, later that year, I learned Java in a Computer Science class in 
High School.  I hated that but I slightly understood it.
My Stepdad started getting into Python around that time (he'd been a 
professional  C programmer for 15+ years).
I decided to pick it up after a while talking to him, and I found it 
much less difficult to learn.
And now I'm half-way through with my second year in College as a  
Computer Science major ^_^.

Of course this wouldn't apply to everybody, and the fact that I was 
fairly young when I tried to learn C++ I'm sure had an effect.
But I think if I hadn't picked up Python, I wouldn't be a Computer 
Science major now.
As it turns out, all of the classes at my school are in C++.  But 
despite the fact that I came here with barely any C++ experience,
I had _programming_ experience, and that, as they say, made all the 
difference.

To address some of your other questions:
No, updates to Python don't usually cause issues.  With the exception of 
Python 3000, they don't break backwards compatibility
as far as I know.

My understanding:
Pygame 1.7 works in both Python 2.4 and 2.5.  The problem is that no one 
has made binaries for Windows.
So there's no installer for 1.7 and 2.5, but it's possible.  No one took 
the time, because 2.5 came out around the time when pygame 1.8 was set 
to come out,
so everyone assumed that was a natural time to transition.  Obviously if 
I'm wrong feel free to correct me.
> I'm sorry if this is a horribly dumb question but I've been looking
> around and I can't find the answer to these on my own.  Thank you all
> for any help you can give me.
>   
No, there are no dumb questions on the Tutor list, just questions that 
are poorly asked :)
And your questions all made sense, so I was happy to reply.

In conclusion,
Python + Pygame would be great for a turn-based strategy game.  It's not 
something that requires extremely fast graphics processing,
so the speed hit from using P&P versus C++ and SDL would be easily made 
up, and surpassed, by the faster development time of using P&P.

And the Tutor list would be happy to help you on your quest to learn 
Python, if that's what you choose.
If you were thinking of making a First Person Shooter, my recommendation 
might be different.
But given your goal, I think Python's the better language to achieve 
that, and in a realistic time-frame.

One thing you might strive toward, depending how much time you have to 
devote to learning Python,
is that in 3 months or so, the Pyweek game programming competition is 
coming up.
I find that, by them giving you only a week to make a game, it really 
opens your eyes to the design issues
that will present themselves whenever you begin to make your turn-based 
strategy game.
Even if you don't finish a game (I've competed in 3 Pyweeks so far, and 
haven't ever completed a game enough
that I would submit a final entry), it's a great learning experience.

Sorry for the long-winded reply ;)

Hope That Helps,
-Luke