I think Python's functional nature is largely misunderstood. For instance, from a Lambda the Ultimate post on Python 2.5 (re: partial):

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?

This comes up a lot. It doesn't help that some people often say with glee that Guido has said Python isn't a functional language. Like it's a big stick in the eye to every Lisper.

My own interpretation is that Guido has bristled at the suggestions by functional programming proponents that Python take on certain features simply because they are in other languages. These arguments are often presented with little justification involving real use cases. Similarly people will argue for features -- like truly private instance variables -- with the argument that this is required for Python to be a "real" object oriented language. The functional people at least have a pleasant academic air to their claims; the OO people often finish their argument with a "this is necessary for Python to be taken seriously in the enterprise."

But I digress... in reality, Python is a pretty decent functional programming language, with functional alternatives to many mutating operations (e.g., + instead of .extend(), sorted() instead of .sort()), closures, many immutable types, you can use tuple as the poor man's cons, and so forth.

If its any indication, the OO-flavored interface and adaptation proposals have lingered for years, in large part because Guido's resisted, or at least his apathy towards them. When generic functions were brought up as an alternative -- a much more functional approach to the same problems -- he warmed to it quickly.

Decorators are another case where a major functional feature has been adopted in Python, with pretty good uptake. It's not a pattern or syntax I see in other functional languages that much (at least I'm not aware of it), but it's still a strongly functional feature and is serving as the basis for many other functional constructs (including generic functions).

Some functional concepts are unlikely to get traction anytime soon, like tail call optimization. I would argue because tail call optimization is inaccessible to programmers who aren't steeped in recursive theory, and rather boring in its effect.

Lambda is syntactically -- not semantically -- awkward, but Python has true closures so the fundamental technique is still just as available. If you read Guido's explanation about why lambda isn't being improved, nor another function-expression syntax added, it's not that he thinks the idea of first class functions is wrong. First class functions are used all over the place in typical Python programs. It's just an issue of syntax.

The functional module itself is more about introducing functional language into Python, without rephrasing Python as a whole in those terms (hence partial is not added to builtins). Also it's just a place to put some functional patterns. Though there was discussion of renaming that module to just to functools, because the scope seemed a little funky -- there are functional constructs elsewhere in the standard library already (e.g., itertools), and some other routines seem related but not really "functional".

But I'm still curious: what other functional concepts aren't in Python that people think should be? Functional patterns that rely on removing ideas won't work -- like removing mutation -- but what is there that could be added to Python to make it more functional-friendly? I honestly can't think of a whole lot.

• Explicit lazy evaluation might be nice; there's some cookbook recipes for that I think (but I can never find things there when I want them), but they fail in a couple ways (not major ways -- things like isinstance) and feel a bit syntactically awkward.
• There's no linked list (though like I said, tuple can fake linked lists); linked lists allow extending a list without modifying the original list, and so allow some functional techniques.
• Macros just happen to be in Lisp, I don't see how they relate to functional programming in any way.
• Tail call optimization. Yawn.
• Blast, I knew I had another one, but I've forgotten it while looking up links.