Question

I see what seems like a majority of Python developers on StackOverflow endorsing the use of concise functional tools like lambdas, maps, filters, etc., while others say their code is clearer and more maintainable by not using them. What is your preference?

Also, if you are a die-hard functional programmer or hardcore into OO, what other specific programming practices do you use that you think are best for your style?

Thanks in advance for your opinions!

Answer 1

I mostly use Python using object-oriented and procedural styles. Python is actually not particularly well-suited to functional programming.

A lot of people think they are writing functional Python code by using lots of lambda, map, filter, and reduce, but this is a bit over-simplified. The hallmark feature of functional programming is a lack of state or side effects. Important elements of a functional style are pure functions, recursive algorithms, and first class functions.

Here are my thoughts on functional programming and Python:

• Pure functions are great. I do my best to make my module-level functions pure.

  • Pure functions can be tested. Since they do not depend on outside state, they are much easier to test.
  • Pure functions are able to support other optimizations, such as memoization and trivial parallelization.

• Class-based programming can be pure. If you want an equivalent to pure functions using Python classes (which is sometimes but not always what you want),

  • Make your instances immutable. In particular, this mainly means to make your methods always return new instances of your class rather than changing the current one.
  • Use dependency injection rather than getting stuff (like imported module) from global scope.
  • This might not always be exactly what you want.

• Don’t try to avoid state all together. This isn’t a reasonable strategy in Python. For example, use some_list.append(foo) rather than new_list = some_list + [foo], the former of which is more idiomatic and efficient. (Indeed, a ton of the “functional” solutions I see people use in Python are algorithmically suboptimal compared to just-as-simple or simpler solutions that are not functional or are just as functional but don’t use the functional-looking tools.)

• Learn the best lessons from functional programming, for example mutable state is dangerous. Ask yourself, Do I really want to change this X or do I want a new X?

  • One really common place this comes up is when processing a list. I would use

    foo = [bar(item.baz()) for item in foo]
    

    rather than

    for index, _ in enumerate(foo):
        foo[index] = bar(foo[index].baz())
    

    and stuff like it. This avoids confusing bugs where the same list object is stored elsewhere and shouldn’t be changed. (If it should be changed, then there is a decent chance you have a design error. Mutating some list you have referenced multiple places isn’t a great way to share state.)

• Don’t use map and friends gratuitously. There is nothing more functional about doing this.

  • map/filter are not more functional than list comprehensions. List comprehensions were borrowed from Haskell, a pure functional language. map and especially filter can be harder to understand than a list comprehension. I would never use map or filter with a lambda but might if I had a function that already existed; I use map a decent bit.
  • The same goes for itertools.imap/ifilter compared to generator expressions. (These things are somewhat lazy, which is something great we can borrow from the functional world.)
  • Don’t use map and filter for side effects. I see this with map a lot, which both makes hard-to-understand code, unneeded lists, and is decidedly not functional (despite people thinking it must be because of map.) Just use a for loop.
  • reduce is confusing except for very simple cases. Python has for loops and there is no hurt in using them.

• Don’t use recursive algorithms. This is one part of functional programming Python just does not support well. CPython (and I think all other Pythons) do not support tail call optimization. Use iteration instead.

• Only use lambda when you are defining functions on the fly. Anonymous functions aren’t better than named functions, the latter of which are often more robust, maintainable, and documented.