Robert Brewer <[EMAIL PROTECTED]> wrote:
> The word "execution" to me implies "statements", and > although some functions somewhere are called behind the scenes to > evaluate any expression, the lambda (and its potential successors) > differ from "def" by not allowing statements. They may be used to "defer > execution" but to me, their value lies in being static > expressions--object instances which are portable and introspectable. > This is where LINQ [1] is taking off: expressions are declared with > "var" (in C#). I used Expression() in Dejavu [2] for the same reasons > (before LINQ came along ;), and am using it to build SQL from Python > lambdas. I had to use lambda because that's Python's only builtin > support for expressions-as-objects at the moment, but I'd like to see > Python grow a syntax like: > > e = expr(x: x + 1) I see what you mean, but in a way you're still agreeing with me :) Your expression-as-objects proposal is very clever, but to me (and as far as this thread is concerned) it still allows to write a "decorated" piece of code (expression), pass it around, and execute (evaluate) it later. This is what I (and others) mainly use lambda for, and your expr() thing would still serve me well. Instead, itemgetter() and friends are going to a different direction (the expression which is later evaluated is not clearly expressed in familiar Python terms), and that's what I find inconvenient. -- Giovanni Bajo _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
