Artificial Intelligence: A Modern Approach

AIMA Python Code Guidelines

Rationale for the AIMA Python Project

We already have a body of existing Lisp code; why do we need a Python version (especially when the Lisp version is not yet complete)? Several reasons:

AIMA Python Project Goals

Goals in order of importance:
  1. Identify errors in the book before it is published. (So need key algorithms coded and tested before August 2002.)
  2. Show how the pseudo-code in the book can be implemented. (So be faithful to code in the book.)
  3. Give reader/programmers a playground to experiment with and extend. (So add scaffolding and examples and documentation for them to use.)
  4. Give reader/non-programmers informative graphical demos they can run and observe. (So make nice GUIs and demos that show how algorithms work.)

Not goals

Don't worry about the following:

Coding and Style Conventions

It will probably be summer 2002 when this is released, so it is safe (and encouraged) to use Python 2.2 features like nested scope, list comprehensions, generators and iterators (including "x in dictionary"). I want the file structure to be not-too-confusing, so I'm leaning towards a single flat directory, with most files around 300 lines, but some 600 or even 1000 (much like the Python libraries). There will be at most one file per Chapter, and sometimes one file for several chapters: agents.py (Chapter 2), search.py (Chapters 3-4), etc. Possibly the GUI components will be in separate files (agents-gui.py, search-gui.py, etc.).

In general, follow Guido's style conventions. I released a version that deviated from the guidelines (I had 2 spaces per indent, and _ instead of self in methods), and was quickly shot down politely asked to change by python-dev. I agreed with their suggestions, so now we're left with:

Scope

What programs do we need? The trickiest part about this is that we want a way to attach GUIs to code without making the code ugly. So the code should be able to run stand-alone, and use some kind of notification protocol to a GUI that may or may not be running. You gotta love VPython, an environment for doing 3D physics simulations. There, all you do is create objects like "ball = Sphere()", and modify them like "ball.pos = ball.pos + ball.velocity * dt". The way it works is that a separate thread runs the display window, and when any VPython object is created it gets registered with the latest display window (a compromise: makes it harder to do multiple windows, but the resulting simplisity is worth it), and the display window's thread monitors all its objects for change in position, color, size, etc. I don't think we want to use VPython per se, but we should steal their approach. For 2D grid environments, its easy: we launch a separate thread that monitors all the objects in the enviornment (which we keep track of), and updates the display as necessary. So really there's only one line of code in the Environment class that has to know about the possibility of displays.

Let's also look at DDD, GVD, TiX, IDE Studio, PyDoc, and surely other projects.

AI: A Modern Approach by Stuart Russell and Peter NorvigModified: May 21, 2003