Recently in Python Category

Oh no! Not another perforce post. Spare us. We're not even using perforce anyways. Uhm. Have those guys left? Ok, well then for the rest of us that are left, I'm going to assume that you either use perforce happily at work or you are forced by some guy to use it. If you're the latter, then you might look envily at other modern source control systems that literally run circles around this old beast. I'm not kidding, running circles really means that you in other systems have adopted branching as the most basic operation you do.

I think the pragmatic programmer advices you to learn one new programming language each year. While this sounds perhaps plausible, I think this can be unattainable for the average non genius depending upon what you define learning as. Much like chess, programming languages are complex yet deceptively simple. You can teach the rules of chess to a novice in matter of minutes. Indeed within the hour a complete novice could be playing games on his/her own. Of course the games will usually end in disaster (and perhaps tears depending on age of the player). To learn the syntax of a new language is pretty easy. With reasonably good memory you could probably do this within a day for a simple enough language (i.e. not C++). If we call this learning the language, then sure we can follow the initial advice, but what would the point be? That would be aching to just memorize a new table each year to stretch your memory muscles.

I'm a big fan of continuous integration, small checkins and very quick checkins. It's easier to debug afterwards and trying to puzzle together from perforce history afterwards is much easier when the changes are small and atomic. Now, that's what I like to do. Sometimes things don't really work out in the real world like you want it to so the other day I found myself with the fun situation of having two weeks worth of changes to try to integrate back into the main line. Of course nothing was backed up, nor did I feel particularly worried about it at the time. I had however done a lot of work, some of the changes involved the fruits of heavy thinking and other changes were the result of an hour or two of menial changes to the code that was a result of some other change.

Sometimes you wind up with changes in your source control system that shouldn't be in there, or you hit the submit button in perforce when you really meant just update the description. Anyways, you find yourself with a changelist that you want to roll back...

Hotloading was for a while, well a hot, topic in the game development industry. As games progressed from being very simple programs to more of world simulators today the issue of tweaking and how assets are handled became more of an issue. When your data fits on a standard floppy disk it's not that bad, but when you have your system administrator breathing down your neck because your using up a Gigabyte of disk each night things become complicated.

Bringing data into your program is always a source of problems. Problems like filesystems, paths and unreliable system calls sound familiar? These problems are not the ones you want to battle with in addition to your unit tests. There is light at the end of the tunnel though. Static data in the executable. We've all done it, quick hardcoded tables inline with the code. Taking it to the next step is simply integrating this into the buildstep and creating these tables from ordinary data, bypassing the filesystem at runtime completely.

This little article will explain how to setup an environment for developing python programs. It will explain the different components and the workflow for developing slightly larger programs in python since the small tutorial ones are pretty much covered and they always (in my opinion) leaves out the really hard stuff.