Skip to content
T. Scot Clausing edited this page Feb 7, 2015 · 3 revisions

Here lie answers to "why" specific decisions were made for pypethon. Keep in mind that pypethon is presented as a two(ish)-hour tutorial, which is the key constraint that will guide a lot of decision making.

Values

In the spirit of being agile, I'll say that "while there is value in the items on the right, we value the items on the left more." And also in the spirit of being agile, I'll use the things on the left as an excuse to not do the things on the right (/s):

  • clear > correct
  • compact > complete

You read that right: pypethon may be incorrect and incomplete, but I'll do my best to deliver on the other two points. It's a toy.

Why ...?

  • Why write our own REPL instead of using the code module?

The tutorial examples use as few dependencies as possible and try to be compact and explicit: while True: print(evaluate(input("tutorial> "))) doesn't leave much up to the imagination, and neither does the implementation of def evaluate(source): return eval(generate(parse(lex(source))), {}).

  • Why is singledispatch used in the parser and generator?

I'm not a huge fan of singledispatch, but it makes these two parts of the compiler super easy to write. The translate() and generate() functions are implemented as as a single recursive "single dispatch" function with multiple implementations.

Edit: The singledispatch function in the parser is actually named ast. Sorry about that.

  • Why are you using Python 3 function annotations (poorly)?

I thought it would add value. Turns out it's just confusing. 🙈

  • Why are you using doctests?

Because I ❤️ doctests. They provide an immediate (and correct) example in the source. Doctests don't typically cover edge cases, they stick to the happy path, so they're certainly not a replacement for a full suite of unit tests.

Clone this wiki locally