Marko Rauhamaa <ma...@pacujo.net> writes: > "BartC" <b...@freeuk.com>:
>>> x = [f, g][cond]() >> It will select f or g (which should refer to functions), and call one of >> those depending on cond. That's not a problem. >> >> The problem is it will still evaluate both f and g, > > That's not really the problem. The problem is in readability. Readability is in the eye of the beholder. The evaluation is the central concern here. > However, the "[f, g][cond]()" technique is how pure lambda calculus > implements conditional branching so it is interesting in its own > right. Yes, but lambda calculus constructs have no meaning without an evaluation strategy ("reduction" strategy in lambda calculs parlance). > IOW, you can do "short-circuiting" in purely functional programming: > > j = j + 1 if j < 10 else 3 > <=> > j = (lambda: 3, lambda: j + 1)[j < 10]() This is just a way to delay evaluation *of the potential results*, i.e., instill a bit of lazyness. One could object that, again, both expressions in the tuple have been evaluated (building two lambdas), only one of which is finally called. I guess that's what BartC meant. -- Alain. -- https://mail.python.org/mailman/listinfo/python-list