To test this error case interactively, the pull-down list includes an “Other” name, which
produces a similar error page reply. Adding code to the script’s table for the COBOL
“Hello World” program (and other languages you might recall from your sordid de-
velopment past) is left as an exercise for the reader.
For more example invocations of our languages.py script, turn back to its role in the
examples near the end of Chapter 13. There, we used it to test script invocation from
raw HTTP and urllib client-side scripts, but you should now have a better idea of what
those scripts invoke on the server.
Refactoring Code for Maintainability
Let’s step back from coding details for just a moment to gain some design perspective.
As we’ve seen, Python code, by and large, automatically lends itself to systems that are
easy to read and maintain; it has a simple syntax that cuts much of the clutter of other
tools. On the other hand, coding styles and program design can often affect maintain-
ability as much as syntax. For example, the “Hello World” selector pages of the pre-
ceding section work as advertised and were very easy and fast to throw together. But
as currently coded, the languages selector suffers from substantial maintainability
flaws.
Imagine, for instance, that you actually take me up on that challenge posed at the end
of the last section, and attempt to add another entry for COBOL. If you add COBOL
to the CGI script’s table, you’re only half done: the list of supported languages lives
redundantly in two places—in the HTML for the main page as well as in the script’s
syntax dictionary. Changing one does not change the other. In fact, this is something
I witnessed firsthand when adding “Python2” in this edition (and initially forgot to
Figure 15-24. Response page for unknown language
1192 | Chapter 15: Server-Side Scripting