Python in game development?

[Gerry Quinn]

In article <cMYq5.9365$D7.377817 at news-west.usenetserver.com>, kragen at dnaco.net (Kragen Sitaker) wrote:
>In article <T1Ze5.9877$r4.5093 at news.indigo.ie>,
>Gerry Quinn <gerryq at indigo.ie> wrote:

>>Changing things at random and hoping the problem goes away is not the 
>>way to fix bugs.
>
>In general, I agree with you.  But there are exceptions.
>

Good points.  (Though incremental compilation means that it only takes a 
few seconds to change these things even with a compiler.)

Still, plenty of coffee and pondering the source leads to the most 
bulletproof code, IMO.  Most of the examples aren't really to do with 
bug-fixing.

Gerry Quinn                                   
-- 
http://bindweed.com
Puzzle / Strategy Games and Kaleidoscope for Windows
Download evaluation versions free, no time limits
New: Unique 2-player strategy game "Zen"


>There are times when you don't know what your program should be doing
>--- for example, what size to make a window border for a pleasant
>visual effect, or which options to put on the main menu and which to
>relegate to a submenu.
>
>At these times, instant turnaround is a very useful thing to have.
>These times seem to occur rather frequently in my development
>experience.
>
>There's also the argument that, if I make ten changes and then rerun my
>test suite, a failure can be caused by any of the ten changes; while if
>I rerun the test suite after each change, the failure can only be
>caused by the change I just made.
>
>And there are times when the libraries or platform simply are not doing
>what the documentation claims they will do; I run into this constantly
>when programming in JavaScript.  Instant feedback makes characterizing
>their behavior much more pleasant.
>
>There's the final argument that correcting errors in your understanding
>of your program as soon as possible is a very useful thing.  When I'm
>programming in environments with a single-stepping debugger, I usually
>single-step through every line of my code the first time I run it to
>make sure it's doing what I think it's doing.  Read-eval-print loops
>are also helpful for this kind of thing.