Lambda the Ultimate

yeah, espesially as GvR's attitude so far seems to have been that functional programing is not in the style of python, and should be avoided. With the proposed removal of lambda and so on. Is this a change in policy? Will they make functional programing in Python reasonable? do we get tail call optimisations?

I see this as a way of quelling the FP advocates' criticisms of Python. No language changes, just a module with some FP tools in it. I don't expect to see language-level changes, like tail call optimization.

Depressingly, TCO is just as much an OO thing as it is an FP thing, at least at the technical level (of course, culturally...)

Felleisen talks about this in section 3 (starts at page 51)
of this presentation.

The proposed removal of lambda, map, filter etc weren't due to any rejection of FP concepts - they were because they were either ugly (lambda), or redundant with the addition of list and generator comprehensions (Note that all that was proposed for map / filter / reduce was taking them out of the default namespace - there is nothing requiring them there rather than in a seperate module a la functional.

Most of pythons recent features seem to be moving in a more functional direction - not less. Since 2.0 we've had nested scopes, List comprehensions borrowed from haskell, lazy sequences via generators and various other minor additions (like partial)

At last night's ACCU (Silicon Valley) meeting, Guido gave a talk about Python 3000. It was a warmup for his keynote speech to be given at the ACCU's annual conference, which will be held in Oxford in about two weeks.

(Python 3000 aka Python 3.0 or Py3k is the nickname for the version that is finally "allowed" to break backwards compatibility, and fix a number of inconsistencies, though it won't be a wholesale language redesign. See the Py3k PEP for details.)

To address your specific concerns, Li: (As far as I understand the Py3k plans ...) Python will not become a functional programming language. A standard requiring TCO implementation is unlikely. Lambda will neither be removed, nor will it be likely to be extended to allow multiple statements. List comprehensions will likely become syntactic sugar for a list view of a generator expression. Several of the builtins that currently work with or return lists will be changed to return either iterators or views.

IMHO, the last two points combine to permit a few slightly more FP-like programming idioms than are currently common in Python.

Well, naturally you could just use a function:

def iif(condition, trueAnswer, falseAnswer):
   if (condition):
      return trueAnswer
   else:
      return falseAnswer

logging = 1

level = iif(logging, 1, 0)

But then that means that both the true and false branches have to be eagerly evaluated. Perhaps a lazy evaluation of function parameters is in order? Nah, too much like FP.

Can be done lazily with lambda:

def iif(cond, true, false):
    if cond:
        return true()
    else:
        return false()

logging = 1

level = iif(logging, lambda:1, lambda:0)

I think the issue here with lazy evaluation is that it is not locally understandable. That is, you'd have to know what kind of function iff was before you could tell if the expressions would always be evaluated or not. That's a pretty major semantic change based on a dynamic lookup of the "iff" variable.

With a dynamic environment you don't want to yank the programmer's legs out from under him by introducing things like this; at least you can understand a function call without understanding anything about the other end. But with lazy evaluation you'll lose that.

It would seem to me that if the lambda expressions eschew side effects then lazy evaluation should be equivalent to eager evaluation. So, it isn't really lazy evaluation that causes you to lose understanding of a function's behavior, it's the existence of side effects. Right?

...either the stream has no contents. Or perhaps an infinite recursion. Or maybe you just don't want the performance hit.

Most typical case that I constantly encounter is null objects.

string x = (obj == null)? "" : obj.ToString();

Anyhow, you have a case here where the true or false branch may be invalid if eagerly evaluated. That's probably the more immediate concern in this particular evaluation construct.

Well, computational effort is a side effect of a sort, as is halting, and lazy evaluation has substantial effects on both of those. And there's no way to statically determine if side effects exist in a hybrid language like Python. But sure, if Python was a different language, lazy evaluation might work just fine ;)

Personally, though, my programs are primarily motivated by the existance of side effects. If it wasn't for side effects, I could just *imagine* I had created a working algorithm, without bother to run it.

What kind of genericity are we talking about? Any links?

(I checked, and it's April 10th already, so I guess this isn't an April Fool's joke...)

Guido van Rossum's Weblog

Python 3000 - Adaptation or Generic Functions?

Dynamic Function Overloading

I'm going to stick to the term "(dynamically, or run-time) overloaded functions" for now, despite criticism of this term; the alternatives "generic functions", "multi-methods" and "dispatch" have been (rightly) criticized as well.