The Python interpreter

The Python interpreter draft.  

Other comments:
- I've checked in tests, although they're not part of the 500 lines / not for inclusion in the book.  (They're not that interesting anyway - just verifying that little snippets of Python do the right thing.)
- It was less work than I thought it would be to adapt this from @nedbat's byterun, so we should make sure he gets appropriate credit.
I think at this stage, I have a hard time appreciating the block stack / data stack division because we've frontloaded the discussion of a lot of Python language features -- in this case, it sounds generators are the primary motivator for this separation. Would we still have it in the absence of generators? 

If you're looking for a "buildup" or to gain some momentum in the introduction, I might:

- start with just the idea of call/return semantics and possibly namespacing, and describe how we might implement those semantics with a (possibly simpler?) stack machine. What would a frame need in this case?
- Now add the problem of dealing with one of (a) exception handling or (b) generators. Explain how we need to extend our machine model then.
- Finally, add the missing semantic(s) we need in the stack machine to support everything we need.

It might be worth making mention of how this sort of thing legitimately used to be done in hardware, and just how neat it is that we can munge our virtual machine model to containing just the right components for what we need it for.