Monthly Archives: December 2004

Why I Teach

Every term, a few students ask me why I teach when the university doesn’t pay me for doing it. Here’s the answer I gave a CSC207 class at the University of Toronto in December 2003:

When I was your age, I thought universities existed to teach people how to learn. Later, when I was in grad school, I thought universities were about doing research and creating new knowledge. Now that I’m in my forties, though, I’ve realized that what we’re really doing here is teaching you how to take over the world—because whether you like it or not, you’re going to have to one day.

My parents are in their seventies, and retired. They don’t run the world any more; instead, it’s people my age who pass laws, decide whether interest rates will go up or down, and make life-and-death decisions in hospitals. As scary as it may be, we’ve become the grownups.

Twenty years from now, though, we’ll be heading for retirement, and you will be in charge, because there won’t be anyone else to do it. That may sound like a long time when you’re nineteen, but let me tell you, you take three breaths, and it’s gone. That’s why we give you problems whose answers can’t be cribbed from last year’s notes. That’s why we put you in situations where you have to figure out what needs to be done right now, what can be left for later, and what you can simply ignore. It’s because if you don’t start learning how to do these things now, you won’t be ready to do them on your own when you have to.

Stirring stuff, isn’t it? ;-) But it’s not the whole answer. I don’t just want my students to make the world a better place so that I can retire in comfort. I want them to make it a better place that’s the great adventure of our times. Forget about landing on the moon and unraveling the genetic code: when future historians write about our era, what they’ll focus on is that for the first time in history, our species started taking the Golden Rule seriously.

Just think: a hundred and fifty years ago, most societies still practiced slavery. A hundred years ago, when my grandmother was a young girl, she wasn’t legally a person in Canada. Fifty years ago, most of the world’s people suffered under totalitarian rule; in the year I was born, judges could—and did—order electroshock therapy to “cure” homosexuals. Yes, there’s still a lot wrong with the world, but look at how many more choices you have than your grandparents did. Look at how many more things you can know, and be, and enjoy. And most importantly, look at how many other people can too.

This didn’t happen by chance. It happened because millions of us made millions of little decisions, the sum of which was a better world. For the most part, we don’t think of these day-to-day decisions as being political, but they are. Every time we buy one brand of running shoe instead of another, every time we choose to take this class instead of that one, every time we give the homeless guy on the corner fifty cents (or don’t), every time we decide to shout an anatomical insult instead of a racial one at a cabbie who shouldn’t be allowed to drive a shopping cart, we’re putting our weight behind one vision of what the world should be rather than another. We don’t think about this bigger picture most of the time—we’d be paralyzed if we did. But the last century and a half shows that once enough people make “doing the right thing” a habit, the big picture more or less takes care of itself.

In his 1947 essay “Why I Write”, George Orwell said:

In a peaceful age I might have written ornate or merely descriptive books, and might have remained almost unaware of my political loyalties. As it is I have been forced into becoming a sort of pamphleteer… Every line of serious work that I have written since 1936 has been written, directly or indirectly, against totalitarianism… It seems to me nonsense, in a period like our own, to think that one can avoid writing of such subjects. Everyone writes of them in one guise or another. It is simply a question of which side one takes…

Replace “writing” with “teaching”, and you’ll have the real reason I’m taking on twenty students next term. Every line of code you write changes the world in some small way. Every deadline you meet, every security hole you don’t plug, every user need you satisfy, every disability you don’t accommodate—each one makes tomorrow different from today.

That’s why I teach. You’re shaping the future we’re all going to spend the rest of our lives in. I want you to do things right, and to believe that doing things right is important, because the world doesn’t get better by chance, or on its own. The world gets better because people like you make it better: penny by penny, vote by vote, and one line of code at a time.

What Trac Says About Python

I’ve seen several posts recently about Trac, a baby-SourceForge built on top of Python, SQLite, and ClearSilver (a language-neutral HTML templating system). If you haven’t seen it yet, you should check it out: it’s less than 6000 lines of Python (and 1800 lines of HTML template), but offers bug tracking, a wiki, scheduling, a Subversion browser, and more. I’m going to be using it to manage my undergraduates’ projects starting in January 2005, and nine of those undergraduates are going to be working on Trac itself.

That’s the good news. The bad news is that Trac doesn’t use any of the lightweight Python web frameworks that Michelle Levesque is analyzing in her PyWebOff. It talks directly to SQLite (there’s been talk of using SQLObject as a persistence layer, but its poor performance makes that impractical), and its templating system, ClearSilver, is actually written in C. I’m not faulting the guys at Edgewall—they looked at what was out there, and made the right engineering decision. I’m just wondering why, ten years on, the Python community still doesn’t realize how damaging it is to offer half a dozen half-baked alternatives instead of a single clear answer. Freedom of the press, different systems are best for different things, blah blah blah… I don’t buy it any more. I just want the authors of Quxote, Twisted, WebWare, and the rest to sit down, hammer out their differences, and come up with something that’s as technically and socially compelling as RubyOnRails. Hell, I’ll pay for the coffee, if that’s what it takes…

Unicode in Action

From Pat Smith and Jeffrey Jia, who’ve been working on the Psiphon project:

One of the more challenging parts of getting Psiphon up and running
was the internationalization and localization of the interface. The
problem was Unicode. As we discovered,
Unicode (or rather, pretending it does not exist) is a big problem in
software. In order to ensure that Psiphon would work with “all”
languages, we needed to get a language such as Chinese or Persian
working. Both Chinese and Persian use the UTF-8 encoding, and they do
not use the ASCII character set we are used to dealing with. Chinese
and Persian were two ideal languages to try because Chinese requires
more bites to be displayed, and Persian is also a “right-to-left”
language.

The first big problem was that of the development tools that we were
using to develop Psiphon, not one was able to properly handle the
Unicode characters. During initial tests on the Persian translation
file we were unable to tell if the problem was with our data file, or
with wxPython and PythonCard. After four to five hours of working
along side Michelle Levesque, comparing how our different tools
handled the Unicode, we determined that it was our development tools
that were causing the problem.

Of Komodo, Cygwin, Windows Command Prompt, and IDLE, it appeared
(at first) that IDLE was the best at handling Unicode. Komodo could
probably display the data file when it was opened, but its Python
shell interpreter would print gibberish when it attempted to handle
the data. We determined it was a codec problem with Komodo’s Python
shell, by observing patterns in the gibberish that was returned and
using Google to see if the results were a common occurance when
dealing with Unicode. We had moderate success with IDLE, however,
after further tests with more Unicode, it seemed that IDLE also had
problems dealing with alot of Unicode. We were not able to find any
tool that was capable of handling all Unicode correctly, so we decided
to continue working on the internationalized interface without a
satisfactory tool.

We soon realized that the Unicode was not being displayed properly
because a non-Unicode build of wxPython was installed. After
uninstalling it and installing the correct Unicode build of wxPython,
the problem was still not fixed. wxPython includes a demo application
which includes a Unicode example, with the Unicode build installed,
this demo should run without a problem, this was not the case. After
many uninstalls/reinstalls, it was discovered that there was an old
partial install on the path that was part of an unsuccessful Unix
install under Cygwin. Removing that allowed the wxPython demo to run
smoothly, but Psiphon’s Persian translation was still causing the
program to crash.

Reading the error trace we were able to determine that the problem
was now within PythonCard’s handling of Unicode. The problem was
traced to PythonCard’s multicolumnlist module. A multi-column list is
used in Psiphon to track the connected users, and the headers of each
column require internationalization. By reading through the
multicolumnlist source code, and reading the Python 2.3 documentation
for Types, we found that PythonCard was using
StringType, which according to Python 2.3 does not
include Unicode strings. The PythonCard source would produce an error
if Unicode was given to a multi-column list. By changing all
occurances of StringType with StringTypes
(includes Unicode), we were able to avoid the multi-column list
error. However, it does require users to change their own version of
multicolumnlist.py if they choose to run Psiphon from the source. We
reported the bug to the PythonCard author Kevin Altis, and he posted
on the PythonCard mailing list that the bug will be fixed on the next
release.

Despite all this, we were still getting errors when Psiphon tried
to display Unicode. Since we were sure (well, pretty sure) that the
Unicode wxPython wasn’t the problem, we determined that the PythonCard
resource file was the problem. This lead to many hours of considering
the possibility of redoing the interface entirely in wxPython, which
would have resulted in many hours of work to migrate the existing GUI
away from PythonCard and into just wxPython.

Back to Kevin Altis, who informed us of a bug: Unicode was handled
in resource files in the same way it was handled in the multi-column
list component. Unfortunately, the suggested fix only worked if the
resource file was being written in Unicode, and not dynamically
creating a resource file while a program is running. Robin Dunn of
wxPython gave much appreciated help in examining the resource file
generating code, and with his help we were able to get Psiphon working
with Unicode languages. However, we were unable to get the
“right-to-left” working with Persian. Since we needed Psiphon to be
multi-platform we could not simply use the GTK wxPython build. GTK
itself is able to handle “right-to-left” easily, but wxPython does not
have its own related options.

The Unicode problem took a lot of hours to fix, but forced us to
understand Unicode, and why we should never write a program which does
not handle Unicode properly. We also gained experience in sorting out
problems in open source software. Tracking down a new bug in an
existing tool gave more insight into how the tool itself works. It
also taught us how to better debug code, and to realize that sometimes
the bug may not be in the code you are writing, but rather in the code
from a tool that you are using. Overall, the time invested in fixing
the Unicode problem was worth it for the knowledge that was gained.