mbdriscoll/ctree — pull request #2 by leonardt (2014-02-20 04:13:33+00:00)
Title: Adding basic precedence handling.

Haven't added handling for associativity or UnaryOps yet, but this pasts our two meager tests. I'll definitely be adding some more test cases. However I wanted to get your opinion on the logic. Mainly the subclassing for precedence. This eliminates the need for a separate precedence module. No real benefits or downsides that I can think of, maybe you have some insights if it's a better idea to keep it separate (would it ever be used outside of the context of operators?).

Commit message below
----
nodes.py
* Made all Ops subclasses of a class that intializes it's precedence
and associativity. This moves the logic out of the precedence module,
but I think it makes sense as it makes our ops better encapsulated.
This equates to less imports, as well as hopefully easier handling of
implementation changes further on.
* Added get_precedence() function to Ops which returns there precedence,
assumes currently that all Ops have a field self.precedence with a
valid value, i.e. no error checking. Not sure if we should handle
errors, if we assume that only we are creating Op subclasses then I
think it's safe to assume that self.precedence should exist.
* Added get_associativity(), similar logic for above.

codegen.py
* Added __visit_with_precedence(self, prev_prec, node). works by
calling the normal visit on the node, but then checks if the child
node is a BinaryOp. If it is, then compare precedences and adds if
parantheses are needed. Currently only called by visit_BinaryOp.

TODO:
* Handle associativity
* Handle UnaryOps