Ahem.

You have to pick what to cover. For a beginning Python book, I'm underwhelmed by the need to drag an entirely new and foreign(-to-Python) paradigm into the beginning Python. I say this as someone who does a lot of functional programming, someone who is using a lot of lambda, filter, map, and reduce is someone who is stubbornly refusing to program with the native idioms, which are named functions (defined inline is fine), list comprehension or loop, list comprehension or loop, and loop respectively. It is not that enormous a gain, and will lose from Python fighting you all the way. (Plus you'll probably miss some opportunities to use generators, overload the special methods, and the other things you can do with native idioms, if you're trying to program Haskell in Python.)

When dealing in industry, we can't always hire the best talent, so there is no need to make things overly complex. Simple solutions work best for a lot of scenarios, and I haven't been limited by it yet.

Not to bash Perl, but the whole reason we write in Python is because there were too many people on our team writing in Perl using too many obscure constructs that took too long to review / revise (especially years later when team members changed and code was forgotten in parts)

Pulling in that language-community momentum can definitely make a difference to the social/technical dynamics inside a smaller group.

... if you have multiple developers who cannot or will not find some way to write maintainable code, you have a problem independent of language.

I've maintained some hideous code written by people who had no business being professional programmers. In every case, adhering to a handful of very simple rules would have improved their code dramatically. Only one case needed a language change, and that one was away from a proprietary 4GL.

Metaclasses can do some pretty powerful stuff though. One of those features that you might never need, but if you do, you really do.

    [ (student.name, 'A') for student in students if student.grade > 90]

(Functional programming, IMHO, isn't about maps and folds and filters anyhow; what those are are the tools it uses to gain composability. Python uses other tools for that goal; when in Python, you should use those tools. Ultimately, Python is an imperative language and will have all the associated flaws, functional probably does a better job of composability overall. But if you're in Python, you're not going to build a cute monadic combinator library that you can use in Python no matter how hard you try to box it about the ears with map and reduce, so you might as well use what Python actually has, which is classes and generators and list/generator comprehensions and lots of very overloadable syntax and so on and so forth. maps and folds and filters are the surface of functional programming, not the essense.)

(And yes, you can build a combinator library, you just can't make it slick.)

Reduce is the only one that is not clean in Python ("fold"), and the official word is to use loops. Again, it's usually not that great a loss, but the loss vs Haskell is greatest here. On the other hand, compared against some actually-functional languages you're still not typing much more; Erlang's folds are hardly any better than a Python loop, character-per-character.

    accum = 0
    for i in l:
        accum += i

    lists:foldl(fun (I, Accum) -> I + Accum end, 0, L)

Speak the native idioms of the language you are in. A lot of people are missing a lot of the good things about Python because they are too busy complaining that it isn't something that isn't Python. It isn't functional at its core, but it can be a very powerful, concise language, if you work with it instead of fighting it.

I'm no Python expert, I couldn't say what's idiomatic or not. That being said, I never had the feeling of struggling with the language when using map and filter, quite the contrary.

What's the idiomatic way of doing this?

   suffix_str_lst = map(lambda x: x + "_suffix", str_lst)

    suffix_str_lst = [x + "_suffix" for x in str_lst]

EDIT: You can add a filter in a similar way:

    suffix_str_list = [x for x in str_list if x.startswith("meep")]

    suffix_str_lst = ['{0}_suffix'.format(x) for x in str_list if x[:4] == 'meep']

OTOH, I can see how they could still be a hard concept for a beginner who hasn't done any functional programming before, particularly because they don't read front-to-back like most imperative statements.

EDIT: You can always split complex ones up as well, for most common usages:

  meeps = [ s for s in str_list if s[:4] == 'meep' ]
  suffix_str_lst = ['{0}_suffix'.format(m) for m in meeps ]

I'm only half kidding. The best way to get used to using functional concepts is to actually use them in their native setting, and then apply (giggle) them elsewhere. When you _have_ to solve problems this way, at some point, it clicks.

I can say that it has indeed improved my Python scripting as well.

However I think you have accidentally... consider this short example which shows off first class functions, map, reduce, no side effects, and filtering.

  [(lambda a,b,p:(a+p,b+p))(x,y,2) for x in (1,4) for y in (10,15,22) if x*y > 25]

- Higher-order functions

- Many tasks are just list transformations

What makes things more painful is that Java is so omnipresent in CS education. Since Java only contains such concepts implicitly (and require a lot of verbosity), I haven't encountered many (if any) Java books that go into functional concepts.

It's like learning UNIX without covering pipes. Sure, you can work with UNIX, inadvertently emulate it using redirections from and to files. But it will never be as effective.

It's not as if we are discussing monads (which are also easy to understand, given a good teacher).

It's in a module in the standard library, a module which contains a bunch of tools for working with higher-order functions. Or, in other words, if you've got a Python 3.x installed, you've got a reduce function available. The only difference is that it's no longer in the default global namespace (map and filter still are, of course).

This matches up pretty cleanly with my actual experience of writing Python; I've written a hell of a lot of Python code these past 6-7 years and so far as I can recall I've never used reduce.

(and if you want to get picky about this, keep in mind how much of Haskell requires import statements to get at -- moving less-commonly-used stuff into standard modules is not a bad thing at all)

Functional programming is just hard to explain to people who know next to nothing. Especially in a language like Python where the functional concepts are kind of half-assed.