> I see how it avoids needing to look at the parent node in general, but > if we were compiling by recursively descending through the AST, then > we would know whether Name's would be loads or stores by the time we > got to them (we would already had to have visited an encompassing > assignment or expression)
Python's compiler does recursively descend. However, it is still more convenient to allow uniform processing of expressions, rather than having parameters passed down into the visitor functions. > except in the case of your a = b = c > expression, which I'm curious how Python handles. The natural answer > is for assignment to be an expression (so b = c returns the new value > of b). But Python doesn't do that, so then I'd expect we'd have some > third ast.LoadAndStore() option for b, but examining ast.parse's > behavior it looks like it chooses Store... No, the value of b is never read in this assignment. I'm not quite sure whether you are aware what the *actual* semantics of this assignment is; it is equivalent to tmp = c a = tmp b = tmp (so the assignment to a happens first), and neither a nor b is being read. So it's simple stores into both a and b. >>> -Why can't orelse for ast.If and ast.While default to empty []? >> You want to store None? That would be a type error; orelse is >> specified as "stmt*". So it must be a list. > > A list is actually what I want, an empty one. The problem is that > ast.While and ast.If's constructors default to the opposite, > orelse=None. Same with keywords and args for ast.Call. Admittedly, > adding orelse=[] to the constructor calls isn't terribly burdensome, > but it does make already obfuscated looking AST mangling code even > worse. Ah, that could be fixed. Please contribute a patch. >>> -Why can't I eval a functiondef to get back a function object? >> Because a definition is not an expression. You can only eval >> expressions. > > I understand that if function definitions were expressions, because of > the whitespace syntax there wouldn't be a way to express an assignment > to such an expression. But, why would it be problematic to let them be > expressions anyway? This would be a significant change to the compiler, which would have to learn what bytecodes to compile it to. Feel free to discuss this on python-ideas. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
