I was at a Python user group meeting with Guido a few years back, and I asked him about his plans for functional programming support in Python. He responded that he thought functional programming was a lot less useful than all the hype would suggest, and that, far from planning more support for functional programming, he regretted having put in as much support as he already had. Ideally, he said, he would remove things like lambda instead of making them stronger.

Even things like tail call elimination, he said, would just encourage people to use more recursion, when iteration was easier to read, and in places where TCE would work, the programmer could obviously convert it to iteration himself and should do so for code clarity.

I like Python, and I like a lot of things about functional programming, so it wasn't the answer I was hoping for. Unless Guido has had a change of heart since then, I wouldn't pin my hopes on Python ever becoming a first-rate functional programming language. It's first rate at the things Guido values.

Python has added list and set comprehension syntax, which are just as functional as eg. map and filter. So I don't think it is functional constructs in general he is against, but rather specifically the lispy idioms with map, filter etc. with functions/lambdas as arguments.

Decorators are another example of functional programming added to Python, but with a pythonic syntax.

Python supports both imperative, OO and functional idioms, but generally only prefers one of them for a specific task. For example loops are preferred to recursive functions when appropriate. Objects are preferred to closures for mutable state, so mutation of captures variables has not been supported (support have been added recently with nonlocal, but it has clearly not been a priority).

Python is interesting because it is multiparadigm while trying to avoid fragmentation where you can solve the same problem in totally different styles.

I wish he would add TCE for the sole fact that parsing tree like structures feels much more natural using recursion than it does with a for loop. I am always paranoid that a really deep structure will cause an stack depth exceeded exception.

There's a quote from Guido about private attribute access where he said, "We're all adults", and that leaving the open is beneficial.

Recursion is another tool that he should let us adults use if it solves a problem better and TCE is lovely feature to have. Frankly, if you're using recursion, you either just learned it in a CompSci class or you know what you're doing. Either way, daddy Guido shouldn't tell us no :).

You can use an explicit trampoline to make sure you don't block the stack. It's not as clean, but still better than loops.

I don't know. It seems to me, from reading SICP, that functional programming doesn't mean lambdas or map reduce, it means pure functions as the main programming unit, instead of object or instruction or declaration. Then it is possible to write functional code in python without lambdas, map, using streams (iterators) as the state keeping data structure.

The problem, as always in these discussions, is that no-one wants to define the term "functional programming". Many people will be quite willing, though, to jump on each other for saying things that they believe flow from an incorrect definition of the term.

Anyway, at the very least there's two camps. On the one side, you have the hardcore Scheme folks whose conception of functional programming is "if I can't figure out how to write it with tail recursion it must not be computable". On the other side you have the Haskell folks whose conception of functional programming is "a monad is just a monoid in the category of endofunctors, what's the problem?"

Somewhere in between are people who actually get things done.

Same thing happened with OO, where people have been discussing whether C++ or JavaScript or Python or Smalltalk are "real OO", rather than discussing if the patterns they support are useful or not.

Maybe there is a difference between functional programming and functional programming languages.

I would have thought the broken statement/expression dichotomy would be a bigger annoyance, though I've never used Python in anger myself.

I agree so much. Real functional programming requires an expression oriented language.

I don't remember where I read it, but "watching someone try to do functional programming in python can be painful". I have to agree quite a bit with that. The distinction between lambdas and functions, expressions, etc.

I started doing a lot of programming in CoffeeScript a few months ago, and between the JS underpinnings and the CS syntax you can do things that would just be painful in Python.

What do you mean with lack of persistent data-structures? There are immutable data-structures such as numbers, strings, tuples, and frozensets (unfortunately no frozen dicts) -- seems plenty to me. Or do you mean the technical meaning of persistent data-structures, as in one that gives access to all previous versions?

A good set of persistent data structures would give you all the generality, utility, and performance of Python data structures like lists and dicts and none of the mutability.

I don't know about dicts, but as far as I can tell, tuples give you all the generality, utility, and performance of lists.

A tuple, behind the scenes, is just a type tag, a refcount, a length, and an array of PyObject pointers. A list, instead of having a fixed array of PyObject pointers, has a pointer to a dynamically resizable array of them. Tuples and lists are both iterable, they both have O(1) indexing and fairly efficient internal representations, but the key difference is mutability. A tuple is supposed to be a composite data type; a list is a dynamic array that you store things in.

Aside from mutability, though, tuples can do pretty much anything lists can, and usually a bit more efficiently.

Performance? Unless I'm mistaken you can't update tuples efficiently.

How do you intend to "update" an immutable list? Isn't it... immutable?

Immutable lists can be preppended/popped in O(1)time, without affecting previous versions.

Immutable dicts can have stuff added and removed in O(log n) time, without affecting previous versions.

Scala's immutable vectors can have appending/prepending/concatenation/splitting/insertion/deletion in O(log n) time, without affecting previous versions. it's log base 32, so for any arrays using integer indexes, it'll never go above ~7, so it's basically constant.

Basically, you get (almost) the performance of mutable data structures, except you don't mess up the old versions of the thing every time you change something. It's really pretty incredible, the performance characteristics people manage to get with structural sharing: http://www.scala-lang.org/docu/files/collections-api/collect...

There's still a lookup hit of log-b32n versus contiguous memory immutable vector with O(1). Locality can also an issue with tree-like structures but muted with the large branch factor. Of course the flip side scala gives you the kitchen sink for persistance.

The Scala stuff is impressive. Updated docs at the new site: http://docs.scala-lang.org/overviews/collections/performance...

The new ConcurrentTrie is also a great addition to 2.10.

As a pure function where the returned value utilizes structural sharing with the input values.