danielx wrote: > Bruno Desthuilliers wrote: > >>danielx wrote: >>(snip) >> >> >>>Python's lambda really can't be as powerful as Lisp's because Python >>>does not have expressions that do case analysis (this is not lambda's >>>fault, of course ;). The reason is that you really want to put each >>>case on its own set of lines.
An expression can span several lines. > This enhances readability at the expense >>>of terseness. Since Python's statements are terminated by a newline, or by a ';' > it >>>would be rather awkward to have a kind of expression where good style >>>calls for it to be spread out accross multiple lines. I must be pretty dumb, but I don't see how this relate to the problem of case analysis in lambda expressions ? >>>You can try to simulate these kinds expressions using into a list or >>>dictionary, but this becomes rather messy. I think the only way to get >>>this done properly is to use eval. For example: >>> >>>def recursiveFunction(args): >>> ... # do stuff... >>> choices = { True:"0", False:"recurisveFunction(newArgs)" } >>> return eval( choices[predicate] ) >> >>Why do you want to use eval here ? >> >> >>>The reason that you need eval is that you want to prevent any cases >>>from being executed until you decide which one you want. >> >>What about: >> >>def recursiveFunction(args): >> ... # do stuff... >> ... # that defines 'newArgs' and 'predicate' of course ... >> return (recursiveFunction, lambda x: 0)[predicate](newArgs) > > > Sure, that works, but don't take things so literally. Sorry for being pragmatic !-) > For instance, if > you have a bunch of cases, you might not way to apply the same set of > arguments to all of them. return { 'case1' : lambda: someFunc(args1), 'case2' : lambda: someFunc(args2), 'case3' : lambda: someOtherFunc(args1, arg42), }.get(predicate, lambda: 0)() Still no need for eval()... Now of course there are limits to the exercice, and we're still far away from ML-like pattern matching or Lisp 'case' forms. As you noted, Python is a statement-based language, not an expression-based one like Lisp. This makes a definitive difference. > Also, let's not get distracted from the main point about how doing case > analysis in an expression is ugly, Ugliness is in the eyes of the beholder <wink> > making lambda's weaker in Python > than in the language which inspired them. The fact is that Python "lambdas" are *not* Lisp lambdas. Python "lambdas" are mostly a handy trick to turn a *simple* expression into a closure - and definitively not a basic building block of the language. Daniel, I of course do agree that Python lambdas are nothing near Lisp lambdas - FWIW, Python is not Lisp neither -, but that looks like an apple and banana comparison to me... IMHO, the most obvious problem with Python lambdas is the word "lambda" !-) -- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in '[EMAIL PROTECTED]'.split('@')])" -- http://mail.python.org/mailman/listinfo/python-list