On 2/3/06, Robert Brewer <[EMAIL PROTECTED]> wrote: > Giovanni Bajo wrote: > > Alex Martelli <[EMAIL PROTECTED]> wrote: > > > I understand your worry re the syntax issue. So what about Michael > > > Hudson's "placeholder class" idea, where X[1] returns the callable > > > that will do x[1] when called, etc? Looks elegant to me... > > > > Depends on how the final API looks like. "deffered(x)[1]" > > isn't that bad, but "def x: x[1]" still looks clearer as > > the 'def' keyword immediatly makes clear you're DEFining > > a DEFerred function <g> :) Of course we can paint our > > bikeshed of whatever color we like, but I'm happy enough if > > we agree with the general idea of keeping the same syntax > > in both deferred and immediate execution. > > I don't agree with that "general idea" at all. Sorry. ;) I think the > semantic emphasis should not be on "execution", but rather on > "expression". 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) > > ...where expr() does early binding like dejavu.logic does. [Looking back > over my logic module, I'm noticing it requires boolean return values, > but it would not be difficult to extend to return abitrary values--even > easier if it were rewritten as builtin functionality. Guess I need to > write myself another ticket. ;)] >
Well, maybe what we really want is lambda but under a different name. ``expr x: x + 1`` seems fine to me and it doesn't have the issue of portraying Python has having a crippled lambda expression. I do think that a general solution can be found that can allow us to do away with itemgetter, itergetter, and Alex's methodcaller (something like Michael's Placeholder class). The problem is when we want deferred arguments to a function call. We have functional.partial, but it can't do something like ``lambda x: func(1, 2, x, 4, 5)`` unless everything is turned to keyword arguments but that doesn't work when something only take positional arguments. This does not seem to have a good solution outside of lambda in terms of non-function definition. But then again small functions can be defined for those situations. So I think that functional.partial along with some deferred object implementation should deal with most uses of lambda and then allow us to use custom functions to handle all the other cases of when we would want lambda. -Brett _______________________________________________ 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
