My name is Paul Bissex, and e-scribe.com is my consulting business. I build web applications using as much open source software as possible. From September to June I teach web design and other important non-photographic professional skills to photographers. In the '90s I wrote technology commentary and reviews for magazines, newspapers, and web publications, including Wired, Salon.com, FamilyPC, the late lamented Web Review, and the Chicago Tribune. Feel free to email me.
I'm co-authoring a book, "Python Web Development with Django", with Jeff Forcier and Wesley Chun. It will be published by Prentice Hall in July 2008, but is available for pre-ordering on Amazon now.
This site is built on a fresh trunk checkout of Django, running on Python 2.5.1, served by Apache and mod_python. The database is SQLite. The operating system is FreeBSD, on a VPS hosted at Johncompanies.com. Comment-spam protection by Akismet. Vintage topo imagery from the Maptech archive.
Akismet, del.icio.us, Django, dpaste.com, Emacs, FreeBSD, Freenode, jQuery, LaunchBar, MacPorts, Markdown, Mercurial, OS X, Postfix, Python, SQLite, Subversion, TextMate, Trac, Ubuntu Linux, wmii
Copyright 2008
by Paul Bissex
and E-Scribe New Media
There is a classic set of programming exercises called "Ninety-Nine Prolog Problems". Though somewhat tailored to logic programming, they form an interesting set of exercises for other languages. I've seen adaptations of varying completeness for Haskell, Lisp, Perl 6, and Python.
I was reminded of this all by a recent blog post by some bloke called Dave who was using the problems as a way to become more familiar with Python. He used Python's unittest module to test his solutions.
I actually played with these same problems in Python a while ago (before I had found that collection on the Python wiki), and like Dave I decided to incorporate tests. Instead of unittest, though, I used doctest, so the test cases live in the docstring with the description of the problem. For example:
def p31(n):
"""
P31 (**) Determine whether a given integer number is prime.
>>> p31(7) and p31(2) and p31(31)
True
>>> p31(1) or p31(4) or p31(9)
False
"""
if n < 2:
return False
for i in range(2, n/2 + 1):
if n % i == 0:
return False
return True
(No, not the most efficient algorithm!)
I collected all the problems in a single module. At the end is the code that invokes the doctest runner:
if __name__ == '__main__':
import doctest
doctest.testmod()
One motivation for this structure was the idea that I could build a version of the module with just the docstrings and pass function bodies as a blank slate for people who wanted to try their hand at the problems.
I got through about 40 problems, but it's unlikely I'll have the time to finish them any time soon (life got busy, and they get harder as you go). The source is here for anyone who feels like continuing the project, or using the doctest idea to enhance the version on the Python wiki. Keep me posted if you do!
just one advice. There is no need to go from 2 to n/2. You only need from 2 to sqrt(n).
I'm trying to come up with a good excuse. sqrt not a Python built-in? Not enough coffee? Too much coffee?
Comments use Markdown syntax. Your comment will not appear until approved, which may take a few hours or more. Spammers will be torpedoed.
The iPhone keyboard doesn't suck
Python one-liner of the day
7 comments
How not to advocate via Google Code
2 comments
99 problems
3 comments
bitmonk
Obscure "svn mv" problem solved
33 days ago
Charlie
Book news: Rough Cuts and Amazon
34 days ago
Simon Griffee
Django Mercurial mirror tweaks
51 days ago
Jason Calleiro
From PHP to Python
52 days ago
Yuli
dpaste.com
55 days ago
bruce
Neat Python hack: infix operators
59 days ago
David Reynolds
The original Lego Star Wars
67 days ago
At least 29896 pieces of comment spam killed since January 12th. Thanks are mostly due to Akismet.
One trivial optimization is to terminate the loop after sqrt(n) instead of n/2.