In my book, OOP and graphical programming *are* two different things.

I totally agree on this. What I, however, do see as a potential risk here is that the division might lead to students thinking thoughts such as "So now we quit the OOP part and continue with graphics. OK, so no we don't have to worry about those things anymore" Although thoughts like these would be rare, I still feel I need to consider them when deciding on what approach to take in the course. In my experience, stronger students have no problem in seeing the orthogonality of things introduced, whereas the weaker students might find it difficult to even understand that one can use the fundamental structures just about anywhere (e.g. nesting for-loops), as long as the logic holds and the syntax rules are followed. Students like these might get ideas as the one above. Anyway, whatever approach I choose, I am planning on starting with a brief repetition of the basics before rather quickly moving on to OOP. In my opinion, the way you Kirby go about objects is just about perfect, and I am planning on following the same idea. If we were to use the pygsear module together with PyGame, we could go graphical from the very first class. If we, on the other hand, were to use e.g. Zelle's graphics.py (thanks for reminding me about that one, had somehow managed to forget it) I would probably introduce OOP first and then continue with graphics. But then again, there is nothing stopping me from introducing the graphics in the middle of OOP either... Gosh, I just realized that I have a lot of pondering to do over the Easter holiday :) /Linda