Python to drop functional programming support

Posted 23 Jun 2005 at 08:37 UTC by exa Share This

I was sad to read the news item on slashdot about Python's future, a language that I find satisfying many needs. Very well, Guido rants about dropping reduce() and friends in python. Reading his reasoning, all I can say is that he might be getting behind the times.

I think it's plain false that a few imperative programming constructs, concerning simple-minded abstractions over iterators (yield, etc.), can supersede the functional constructs that do it in a cleaner way.

What's worse, he seems to assume that lambda is hard to understand, and so are higher-order functions. I think it isn't. Lambda should be used whenever it's short, and the whole point is making the language truly orthogonal. When it would be long you are better off writing a nested function definition. If people are writing 200 char lambda expressions or insane reduce() or map() expressions and then finding them hard to understand it's their mistake. Since python supports nested function definitions they should be preferred for substantial inner scope functions. The same goes for the use of 'where' and 'let' clauses in Haskell. The code must be readable, and I think we all agree on that.

However, all of this hard-to-understand / easy-to-understand talk has nothing to do with the real utility of a fold, map or filter function. I had the feeling that Guido was missing the point with that argument.

The benefit with higher order functions is not obvious to somebody who fills his code with for loops. That's almost taken for granted. But why is it not obvious to Guido? In my opinion, one of the best part about Python was the support for advanced programming, which Guido wants to eliminate. That support would be missed if that happened.

Instead, I would have liked to see the functional programming stuff extended to make programming in this style even easier, perhaps filling in a few holes that functional programming people could find in python. [e.g. a pattern matching mechanism for instance] It's not just the lisp/scheme addicts. There are quite sane haskell/ocaml programmers who would like to see neighbors around their house. :)


PS: I couldn't find a link to the said article or the news item.

read the long thread in the python-dev archives, posted 24 Jun 2005 at 00:25 UTC by splork » (Master)

before jumping to conclusions.

I think i'll stick to my current version then., posted 28 Jun 2005 at 01:53 UTC by Mysidia » (Journeyer)

And not switch to or accept new releases of Python then, because, face it, these capabilities are a big part of what makes Python useful and nice.

What's the deal with stripping such useful and well-known capabilities from a language in a later release, not to mention that they will doubtlessly break existing code?

I was not aware that Python was beta software, or that we couldn't write programs yet and expect future releases of python to continue to support the same basic kinds of constructs...

Some links?, posted 28 Jun 2005 at 03:03 UTC by Mysidia » (Journeyer)

I do cannot find any recent python-dev discussion relevant to the topic... Searching through slashdot, I cannot find any reference to "python dropping functional support" in the near future.

How about a direct link or two to further explanation of what exactly is going on with the lambdas and reduce() family of functions in Python, why this is to happen, and when/what versions will be effected?

The fate of reduce() in Python 3000, posted 28 Jun 2005 at 08:28 UTC by fxn » (Master)

Maybe you are referring to this blog entry by Guido at

There is another one about making whitespace rules stricter that looks interesting, given the enforced uniformity by design. Granted, some people can't stand those choices, some people love them.

Calm down!, posted 28 Jun 2005 at 15:08 UTC by slamb » (Journeyer)

There's an article at Lambda the Ultimate on the subject.

List comprehensions are not going away.

The whitespace thing was an April Fool's joke.

The lambda keyword in Python has been deprecated for a long time. It's awkward syntax, and Python has function objects...

def foo(x,y,z):
    return x+y+z


foo = lambda x,y,z:x+y+z

have long been equivalent. You can declare a function in global, module, or local scope, reassign to it, etc.

Getting rid of map, filter, and reduce isn't that big a deal. The list comprehensions are clearer. The generator comprehensions are more efficient. And for operator+ and operator*, sum() and product() will stick around.

They're not turning their back on functional programming. They're adding more. PEP 309 will add a standard module for partial function application in Python 2.5.

re: slamb, posted 28 Jun 2005 at 17:53 UTC by exa » (Master)

Well, getting rid of lambda, map, filter and reduce might also show that the designers do not fully appreciate functional programming.

The partial function application is ok, but I just don't see why you would want to get rid of something useful like map or filter. Even C++ has those tools.

About lambda: that's just an inline function definition, the ocaml syntax is better, but python syntax isn't bad at all, in fact it's quite clean. Suppose I want to combine two functions quickly and use this to reduce a list. I too prefer list comprehension to map at times, but when it's simply [ f(x) | for x in l ] I suppose map ( f, l ) is cleaner! As for reduce/fold: there is no replacement for that! Of course I don't care about summing/multiplying.

And yes: this would break a hell lot of code. And removing these, while some half-terrible class system is there. Makes me wonder.


Breaking code, posted 29 Jun 2005 at 01:59 UTC by slamb » (Journeyer)

Python 3000 is a hypothetical future version that breaks lots of code, not just this. If/when it is released, I expect it will be side-by-side with Python2.x.

map, reduce etc., posted 30 Jun 2005 at 22:37 UTC by lkcl » (Master)


map and friends are perfect candidates for comprehending the concepts of parallel programming.

ARGH this is bad.

lambda is GREAT.

no, no nooooo!

re: Lambda, posted 2 Jul 2005 at 22:16 UTC by Mysidia » (Journeyer)

Thank you for the links.

The lambda keyword in Python has been deprecated for a long time. It's awkward syntax, and Python has function objects...

Hi, the lambda is preferable due to the inline nature, your example is not really how one would use lambda.


def z(a,b) : return [1+a(w) for w in b]

x = z(lambda x: x**2, [1,5,6]);

That's much more manageable than

x = z(def blah(x) :
           return x**2,

How about if the next version of the C++ language removed switch() to replace it with an extended if statement, or if the next version of C threw out the a?b:c operator in favor of the 'simpler'

if (A) b; else c;

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page