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.
Hi @akaptur

As I mentioned over email, I find your writing style to be very easy to read. It assumes very little about the reader's background, and thus feels like it is encouraging me to learn more rather than to feel stupid because I don't already know this stuff.

A few suggestions that might round out the chapter:

__Building up the model__

As I mentioned earlier, I feel like we're trying to introduce too many semantics into the stack machine design all at once, and so the reader isn't able to appreciate __why__ our machine model is a good one. I think the ideal situation would be to build `byterun` to handle only call/return semantics first, both in terms of explaining the model and in writing the code, and then building up both the model and the code to handle other semantics later. However, I really don't think we have the room for that :) 

I think a happy medium would be to do this sort of exploration in the introduction, at the "theory" level (i.e. before we see any code.) We can build a stack machine that just handles call/return, and then dig deeper as we add more Python semantics to show how our design needs to evolve to handle these situations. Right now, exceptions and generators are given only cursory mention in the text, but it seems like a fair amount of the complexity of the machine's design comes from trying to support those two language features.

__Exploring "why" more often than "what"__

Once the "theoretical machine" has been designed, I would pay a bit more attention in the coding section as to __why__ we implemented this model the way we did. The one question I'd like to see considered as often as possible is "why did I put this thing here." 

For example, the 4 components that make up the VM implementation are presented without really explaining why these components were the obvious pieces to build our machine from. The `Function` class especially feels like it needs further motivation, because it isn't really a thing that you could point to one a physical stack machine and say "aha, there it is" -- it's more of a factory function that is taking the name of a logical concept. Up until that point, it really felt like we were trying to build a software model of a physical device. Why is this "frame generator" a convenient or good abstraction to use?

A second example; It seems like the vast majority of the virtual machine's behaviour is implemented on the `VirtualMachine` class itself, with the other components primarily serving as data. Why did we do this? Does it make the program easier to reason about? Easier to extend? etc.

Third example; we chose to use plain-old lists as stacks, relying on the `VirtualMachine` interface to wrap the manipulation of these stacks as part of their more specific stack-handling routines for each stack type. Why didn't we have a `Stack` class with basic `push`, `pop`, instead of using raw lists? 

I'm not saying you have to explore all of these things, but this is the sort of exploration that I think might help our readers get the most out of this chapter.

__Emphasizing lessons that can be used elsewhere__

For your conclusion, the question I might ask myself before writing it is: "If the reader of this chapter was going to write an interpreter for some other language, what are the most important lessons / design principles that I think they should take away with them? What are some of the potentially weird or unexpected things that we did in `byterun` that we feel are a good idea in the domain of building this kind of program?"

This is a lot to digest-- would be happy to talk it over further here, over email, or voice if you like.