Guido van Rossum <guido@python.org> writes:
I would at least define different classes for the uptalk versions.
But my main complaint is using the parse tree as a spec at all
Like I said, I actually came up with that structure *before* seeing that it mirrored a grammar element - it honestly seems like the most natural way to embody the fact that evaluating it requires the whole context as a unit and can short-circuit halfway through the list, depending on if the 'operator' at that position is an uptalk version. The evaluation given this structure can be described in pseudocode: def evaluate(expr): value = expr.atom.evaluate() for trailer in trailers: if trailer.uptalk and value is None: return None value = trailer.evaluate_step(value) The code generation could work the same way, iterating over this and generating whatever instructions each trailer implies. In CPython, The difference between the uptalk and non-uptalk version would be that immediately after the left-hand value is on the stack, insert opcodes: DUP_TOP LOAD_CONST(None) COMPARE_OP(is) POP_JUMP_IF_TRUE(end), with the jump being to the location where the final value of the expression is expected on the stack. Assuming I'm understanding the meaning of each opcode correctly, this sequence would basically be equivalent to a hypothetical JUMP_IF_NONE opcode. I don't think a recursive definition for the structure would work, because evaluating / code-generating an uptalk operator needs to have the top-level expression in order to escape from it to yield None.