On the other hand, functional programming isn't getting a warm reception from Guido: Guido says that Python can do without map, filter, and reduce. He argues that removing map and filter is "uncontroversial", and that reduce is just too complicated:

So now reduce(). This is actually the one I've always hated most, because, apart from a few examples involving + or *, almost every time I see a reduce() call with a non-trivial function argument, I need to grab pen and paper to diagram what's actually being fed into that function before I understand what the reduce() is supposed to do. So in my mind, the applicability of reduce() is pretty much limited to associative operators, and in all other cases it's better to write out the accumulation loop explicitly.

Then he goes on to explain that we can have sum(), product() and similar functions to handle the common cases. I don't mind having sum and product, but really, is that all that reduce is for? I understand what he's saying about complexity - I remember when I first learned how to use reduce(), and it was hard. I also remember learning standard procedural programming idioms (like for loops), and that was hard too, but worth learning nonetheless. Just because it takes practice to use a tool, doesn't mean the tool isn't valuable.

One of the things that's most valuable about functional programming is the ability to encapsulate patterns. Reduce() isn't just a function that does something useful, it encapsulates a pattern, just like for loops encapsulate a common pattern of ifs and gotos.

A lot of the motivation for throwing out map, filter, and reduce seems to come from the fact that Python has ugly lambdas:

Why drop lambda? Most Python users are unfamiliar with Lisp or Scheme, so the name is confusing; also, there is a widespread misunderstanding that lambda can do things that a nested function can't -- I still recall Laura Creighton's Aha!-erlebnis after I showed her there was no difference! Even with a better name, I think having the two choices side-by-side just requires programmers to think about making a choice that's irrelevant for their program; not having the choice streamlines the thought process. Also, once map(), filter() and reduce() are gone, there aren't a whole lot of places where you really need to write very short local functions; Tkinter callbacks come to mind, but I find that more often than not the callbacks should be methods of some state-carrying object anyway (the exception being toy programs).

I'm not sure what to say about this. Python's lambdas are ugly. None of its built-in datastructures are written in a functional style, nor are most of its basic constructs expressions. This means you're severely limited in what you can write in a Python lambda, and even if you could use statements in a lambda, the indentation-based syntax looks pretty ugly when you try to use a block of statements in the middle of a function call. Maybe Guido's right, and functional programming doesn't belong in Python. Of course, that would imply that functional programmers don't belong in Python, either... I hear Perl's more receptive these days, and you won't find Ruby or Smalltalk giving up blocks/lambdas anytime soon. Or heck, try a real functional language like Haskell, Ocaml, Dylan, Nice, Scheme, or what have you. Even C++ is getting more functional these days. Too bad to see Python going backwards.