In my experience methodcaller is an occasionally-useful "mid-refactoring feature".

That is, sometimes when I'm making a largeish modification there's a point in the commit series where the natural way to express what's going on involves using methodcaller, then by the time the work is finished the use has gone away again.

methodcaller can be useful in functional programming, like

  close_file = methodcaller('close')
  exhaust(map(close_file, files))

where exhaust is a function that consumes an iterator. Obviously this is a contrived example, but it's a weird transformation -- it turns map from 'call this function on each of a sequence of arguments' to, roughly 'call each of this sequence of functions on a fixed argument'

It’s higher order for the sake of higher order, and unreadable as hell when you return to five full pages of this nonsense a year later. These getter-caller generators are cool to show off, but irl the most naturally readable form is either a plain anonymous function, or a special form suggested by a sibling commenter.

Both by a compiler easily readable by a human unreadable out of purely functional languages by design this high fashion came.

Sometimes you need to do higher order stuff (or, maybe you don't? But it exists for good reason)

Do you think it's better to use a conceptually difficult example to showcase a high order function? Or do you think it's better to show an example where the reader can accurately understand the concept and focus on what the function does?

exhaust((file.close() for file in files)) works.

Like I said, contrived example. Though, it's a specific example of a more general pattern where you have a bunch of objects that you need to send a message to. You might use this for event handling in the guts of a game engine.

I believe exhaust(file.close() for file in files) should work as well, no need for the extra parens.