But there have been some problems.
First, I was originally intending to use the version of Python already installed on our new Mac Minis. It's a version of Python 2.7, perfectly adequate for new programmers with no interest in which version of a language they're using. That would save me the trouble of doing 14 installs of a different version of Python.
But the book uses Python 3. I had looked at several possible books for the class, and hadn't entirely cottoned on to the fact this one had the exercises in Python 3. So I had a choice of trying to have the students see the differences between 2 and 3 on their own from the very first, before they have any idea what they're up to, rewriting the programs for the installed version of Python, or installing Python 3.
I decided to install Python 3.
Later, the book uses the pygame library to give Python graphics and sound capabilities. Unfortunately, there's no distribution package of pygame for Python 3 on Macintosh, only Windows (and possibly some of the Linux distros.)
So I tried to install pygame for 2.7. At least by the time my students get to chapter 17 in the Invent Your Own Computer Games with Python, I believe I'll be able to discuss the 2 vs. 3 syntax differences with them. Hopefully they'll be able to translate on their own. I expect to be doing Python 2 rewrites of the programs myself for next year's classes (unless a working pygame package appears for Python 3 on OS X Lion in the meanwhile).
It took me quite a few tries and a fair bit of my limited class prep time to find a combination of Python and Pygame that works on our school's lab computers. I discuss the details of that on my other blog. But I found a combo that appears to work today (pygame imports, and the first graphics program from the book runs.) I have installed it on 3 out of 14 computers so far, hopefully I'll have time to get it everywhere before the students reach that chapter.
Ass it is, I had already had to spend significant amounts of time developing alternatives to using the rest of the book after Chapter 16. My plan was to shift to turtle graphics, which appear to be bundled with Python 3.2 regardless of platform.
A Bit of a Rant
Frankly, as much as python has worked well for my students so far, if I had known the time and trouble I'd be running into I would never have even started using Python in class. There is no good Python solution here, everything is no better than a 9/10s solution.
Python, by itself, is pretty darn good. The current features in the standard distribution include graphics without requiring any external package installs on all 3 platforms I've run it on: Mac OS X, both 10.6 and 10.7, Win7, and Ubuntu 9.04 and 9.10. It's turtle graphics, but for the needs of my new programmers that fits the bill. I'd like to see standard sound support across platforms. Really, anything that supposes itself to be a general purpose language on this side of AmigaBASIC should be expected to support graphics and sound as standard features. Preferably without a ton of boilerplate. Here's hoping future Python versions can manage this.
The change in the print statement between Python 2 and 3 is maddening. The rationalizations aren't especially convincing to me, at least with respect to breaking backward compatibility and requiring silliness like "end=''" to suppress newlines. What great new ability has been gained for this cost? Nothing that's convinced me of the value yet. I expect this was discussed in PEPs somewhere. Parens, OK, I can possibly see adding those if it does something for added functionality (orthagonality with functions is not a convincing argument, to me.) But failing to provide a simple means of suppressing a newline like the earlier trailing comma, while going to a parametric assignment...that certainly appears well out of line with Python's apparent philosophy.
Now, pygame. No 3.X distributable for OS X? On what's touted as so wonderfully multi-platform? And it's not as if we're talking about a new version of Python that we need to just wait a week or two to get a binary for platform X ready. But Windows gets first class treatment. Mac OS? Not so much. Great multi-platform commitment, there.
I'm not at home to suggestions of compiling my own, I'm afraid. I could, for myself. But the world has a lot of machines that aren't just my own development system. The OS and hardware in our school's lab differs to what I run on my own systems. I haven't the time or desire to set up one of the school's systems as a dev box for porting software, then porting what claims to be a highly popular multi-platform package to the school's computers. Especially when they are a very popular hardware/OS mix already. I shouldn't be expected to put a large commitment of time and energy into getting this working at a point when I don't even know if it has any value to me yet.
And that still doesn't get me a package for Python 3, just for 32/64-bit, unless I move files by hand or make my own installer. While I'm a newcomer to python, for the most part, myself.
Good, but Not Quite Ready for Prime Time
That all said, I think I and my students will get plenty of value out of Python, pygame, and Al's book. But the price of entry for the package deal was too high. And we've still got this Python 2/3 version switch problem sitting in front of us, which I hope isn't going to turn into another big problem, but stay a little problem--though one that still needlessly eats up our limited class time with explanations of syntax differences rather than real new material.
Frankly, I couldn't possibly recommend doing this to others teaching at this level, as things stand at present. Things that would change this:
- A book of the character and caliber of Al's that relies on no external package installs, just a current version of Python. Or,
- An unambiguous install of Python and a matching compatible version of pygame, plus a book with matching code for that version in the exercises. Preferably as a single bundle installed all at once.
Edit: I've read PEP 3105 now. I still don't agree with breaking backward compatibility, as opposed to adding the function and deprecating the statement syntax. I also think there's reason for a simpler newline suppression syntax than the end parameter. Not every Python programmer is going to share the viewpoint of a python-dev wonk. ;) Some of them just want something simple that does the basics (print a string, suppress linefeed as needed--that's all.) In this case, the extended usage has broken the basic usage.
Addt'l edit: Reading "Python Regrets" now. The example syntax there of write() and writeln() would do the trick, from my teacher's standpoint. While I'm aware that redundancy is not a Python value, I think adding write() and writeln() to 3.x while keeping but deprecating the print statement for the term of one major version would have been a better approach (drop print when 4 comes.) Possibly limit print by rolling it back to a more limited version that doesn't allow redirection during 3, if the clock could be rolled back. Obviously at this point it's somewhat too late for that.
