Check out my [blog post](http://mkbernard.com/blog/2014/06/graffiti-a-python-library-for-declarative-computation/)for more background on the "why" of this project. Get in touch if you have anycomments or questions!

The first computation is based on our input (xs), and each additionalcomputation builds up more values based on things we've computed already. It'sconvenient to visualize this computation as a graph with the user inputs at theroot and values we're interested in at the leaves.

graffiti allows you to structure your computation in exactly that fashion:

graffiti finds the relationships between the nodes in your graph and determinesthe optimal execution order. Leaves in the graph are computed lazily which meanswe can choose to only evaluate the ones we're interested in:

```pythongraph({ "xs": range(100) }, _keys={"m", "n"})```

In this case, graffiti will only evaluate what's needed to compute m and n, butnot the rest of the graph. You can also build nested graphs with dependenciesacross nesting levels:

If the optional key is provided as an input to the graph evaluator, it willoverride the default value of the node. This makes it easy to play withdifferent values or settings as the computation flows through your pipeline.

Finally, graphs are resumable. Since a graph object takes a dict as input andreturns a dict as output, you can replay a previously generated dict as theinput to the next thereby reusing all previously computed values:

Using graffiti allows you to structure your computation and the complexinterdependencies therein naturally and efficiently. Most importantly, yourcomputational pipeline is just data. That means it's easy to inspect, easy toreason about, and easy to build tooling around.

This project is still under active development. Contact me on Twitter@SegFaultAX if you have any questions, comments, or bug reports.