Is it readable?

For me: Yes, but I have come to understand, that the Python community often seems to consider list comprehensions a cleaner solution than using map()/filter().

In fact, GvR even considered dropping those functions altogether.

Consider this:

filtered = [item for item in measures if included(item.time, dur)]

Further, this has the benefit that a list comprehension will always return a list. map() and filter() on the other hand will return an iterator in Python 3.

Note: If you want to have an iterator instead, it’s as simple as replacing [] with ():

filtered = (item for item in measures if included(item.time, dur))

To be honest, I see little to no reason for using map() or filter() in Python.

Is it Modifiable?

Yes, certainly, however, there is one thing to make that easier: Make it a function, not a lambda.

def is_included(item):
    return included(item.time, dur)
filtered = filter(is_included, measures)
filtered = [item for item in measures if is_included(item)]

If your condition becomes more complex, this will scale much easier, also, it allows you to reuse your check. (Note that you can create functions inside other functions, this can keep it closer to the place where it is used.)

How does a developer that hasn’t written/learned FP react on code like this?

He googles for the Python documentation and knows how it works five minutes later. Otherwise, he shouldn’t be programming in Python.

map() and filter() are extremely simple. It’s not like you’re asking them to understand monads. That’s why I don’t think you need to write such comments. Use good variable and function names, then the code is almost self explanatory. You can’t anticipate which language features a developer doesn’t know. For all you know, the next developer might not know what a dictionary is.

What we don’t understand is usually not readable for us. Thus, you could argue it’s no less readable than a list comprehension if you’ve never seen either of them before. But as Joshua mentioned in his comment, I too believe it’s important to be consistent with what other developers use – at least if the alternative provides no substantial advantage.

Since developer community is regaining interest in functional programming, it is not unusual to see some functional programming in languages which were originally fully object oriented. A good example is C#, where anonymous types and lambda expressions enable to be much shorter and expressive through functional programming.

This being said, functional programming is weird for beginners. For example, when during a training course, I explained to the beginners how they can enhance their code through functional programming in C#, some of them were not convinced, and some said that the original code was easier to understand for them. The example I gave to them was the following:

Code before refactoring:

var categorizedProducts = new Dictionary<string, List<Product>>();

// Get only enabled products, filtering the disabled ones, and group them by categories.
foreach (var product in this.Data.Products)
{
    if (product.IsEnabled)
    {
        if (!categorizedProducts.ContainsKey(product.Category))
        {
            // The category is missing. Create one.
            categorizedProducts.Add(product.Category, new List<Product>());
        }

        categorizedProducts[product.Category].Add(product);
    }
}

// Walk through the categories.
foreach (var productsInCategory in categorizedProducts)
{
    var minimumPrice = double.MaxValue;
    var maximumPrice = double.MinValue;

    // Walk through the products in a category to search for the maximum and minimum prices.
    foreach (var product in productsInCategory.Value)
    {
        if (product.Price < minimumPrice)
        {
            minimumPrice = product.Price;
        }

        if (product.Price > maximumPrice)
        {
            maximumPrice = product.Price;
        }
    }

    yield return new PricesPerCategory(category: productsInCategory.Key, minimum: minimumPrice, maximum: maximumPrice);
}

Same code after refactoring by using FP:

return this.Data.Products
    .Where(product => product.IsEnabled)
    .GroupBy(product => product.Category)
    .Select(productsInCategory => new PricesPerCategory(
              category: productsInCategory.Key, 
              minimum:  productsInCategory.Value.Min(product => product.Price), 
              maximum:  productsInCategory.Value.Max(product => product.Price))
    );

This make me think that:

• you should not worry if you know that the next developer who will maintain your code will have enough overall experience and some knowledge of functional programming, but:

• otherwise, either avoid functional programming, or put a verbose comment explaining at the same time the syntax, the advantages and the possible caveats of your approach versus a non-functional programming one.

I am a non-FP programmer and recently I was to modify my colleague’s code in JavaScript. There was an Http-request with a callback which looked a lot like the statement included by you. I must say that it took me some time (like half an hour) to figure it all out (the code all in all wasn’t very large).

There were no comments, and I think there was no necessity for any. I didn’t even ask my colleague to help me understand his code.

Taking into account that I am working for about 1.5 years, I think most programmers will be able to understand and modify such code, since I did.

Besides, as Joachim Sauer said in his comment, there often are pieces of FP in many languages, like C# (indexOf, for instance). So many non-FP programmers deal with this quite often, and the code snippet you included isn’t something dreadful or incomprehensible.

I would say definitely yes!

There are many aspects of functional programming, and using higher-order functions, as in your example, is only one of them.

For example, I consider writing pure functions to be extremely important for any software written in any language (where by “pure” I mean no side-effects), because:

• they’re easier to unit test
• they’re much more composable than side-effecting functions
• they’re easier to debug

I also often avoid mutating values and variables — another concept borrowed from FP.

Both of these techniques work fine in Python and other languages that aren’t commonly classified as functional. They are often even supported by the language itself (i.e. final variables in Java). Thus, future maintenance programmers won’t face a humongous barrier to understanding the code.

We had this same discussion on a company I worked for last year.

The discussion concerned “magical code” and if it was to be encouraged or not. When looking into it a bit more it seemed that people had very different views on what actually was “magical code”.
The ones who brought up the discussion seemed to mostly mean that expressions (in PHP) which used functional-style was “magical code” whereas developers who originated from other languages who used more FP style in their code seem to think that magical code was rather when you made dynamic inclusion of files through filenames and so on.

We never came to any good conclusion on this, more than that people mostly think code that looks unfamiliar is “magical” or hard to read.
So is it a good idea to avoid code that seems unfamiliar to other users?
I think that it depends on where it is used. I would refrain from using fp-style expressions (dynamic file inclusion and so on) in a main method (or important central parts of applications) where data should be tunnel in a clear and easy-to-read, intuitive, way. On the other hand, I do not think one should be afraid to push the envelope, the other developers will probably learn FP quickly if they are faced with FP code and maybe have some good in-house resource to consult on the issues.

TL;DR: Avoid in high level central part of the applications (which need to be read for an overview of the functionality of the application). Otherwise use it.

The C++ community recently got lambda’s as well, and I believe they have roughly the same question. The answer may not be the same, though. The C++ equivalent would be:

std::copy_if(measures.begin(), measures.end(), inserter(filter),
  [dur](Item i) { return included(i, dur) } );

Now std::copy isn’t new, and the _if variants aren’t new either, but the lambda is. Yet it’s defined rather clearly in context: dur is captured and therefore constant, Item i varies in the loop, and the single return statement does all the work.

This looks acceptable to many C++ developers. I haven’t sampled opinions on higher-order lambda’s, though, and I would expect much less acceptance.

Post a code snippet to a fellow dev that isn’t as fluent in python, and ask him if he can spend 5 minutes checking out the code to see if he/she understands it.

If yes, you are probably good to go. If not, you should look at making it clearer.

Could your colleague be daft and not understand something that should be obvious? Yes, but you should always program in accordance with KISS.

Maybe your code is more efficient/good looking/elegant than a more straightforward, idiot-proof approach? Then you need to ask yourself: do I need to do this? Again, if the answer is no, then don’t do it!

If after all this, you still think you need and want to do it the FP way, then by all means do it. Trust your instincts, they are better suited for your needs than most people on any forum 🙂