He didn't cover defining first-class functions that I could see in a quick check, didn't cover generators, and I think most disappointingly, didn't cover __metaclass__. That's some critical stuff for Python programming right there, everybody needs __metaclass__.
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.)
I have programmed literally hundreds of thousands of lines of python without using classes or __metaclass__, as a counter example.
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)
You’re implying that language syntax is primarily technical rather than social. I’m not sure I can agree. The reason that Python code uses standard idioms most places you go is that the larger-scale Python community is committed to quite a different set of social norms than the Perl community.
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.
Keep in mind too that the new class decorators can do a lot of what metaclasses were good for, in a way much easier for the uninitiated to figure out. (Partly because once you understand function decorators class decorators seem obvious and straightforward.)
Metaclasses can do some pretty powerful stuff though. One of those features that you might never need, but if you do, you really do.
As far as I know, this piece of code (containing a lambda, map and filter) is standard idiomatic python:
[ (student.name, 'A') for student in students if student.grade > 90]
I'd assert that first class functions are idiomatic python as well and are also critical for python programming. They play an integral part of django, for example.
Yes, that's the idiomatic way of doing it, when people complain about lack of map, filter, and lambdas, they're usually missing an opportunity to do it more easily with list comprehensions. Note that doing this with list comprehensions is pretty competitive with Haskell on a keystroke-by-keystroke basis; insisting that your lambdas MUST have the word lambda and the filter MUST have the word filter and that maps MUST have the word map is getting caught up in the surface appearance and missing the deeper flows, which actually, IMHO, isn't a very "functional" attitude to have anyhow.
(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
vs
lists:foldl(fun (I, Accum) -> I + Accum end, 0, L)
First class-functions are absolutely idiomatic; what's not idiomatic is smashing things together with crazy "and" or "or" chains (or a variety of other hacky approachs) so you can have the magic-goodness-conferring word "lambda" show up in your source, instead of (horrors!) having to give your function a name.
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 thought the book was to be an introduction to programming through Python, that's a good opportunity to show "by the way, you can also see things the functional way...".
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)
If you are okay with a generator instead of a list, then you can flip the square brackets to parentheses and then you do not need to hold the whole thing in memory at once.
EDIT: You can add a filter in a similar way:
suffix_str_list = [x for x in str_list if x.startswith("meep")]
Read that out loud and tell me that doesn't grate on your ears? That's my basic test if code for the book would be understood by the reader. What you have here, this "symbol soup" is what makes programming hard for people in the beginning.
Some of the simpler list comprehensions (like the student one two parents up) are fairly "symbol soup" free, though - and a very clean way of expressing what you want.
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 ]
This one was probably a bit simple to really need that, but it's a bit easier to read. :).
I actually find it really elegant. I fell in love with comprehensions as soon as I discovered them. They were the terse, expressive syntax I'd long been searching for.
Is there a tutorial on learning simple one liners like this? I find myself frustrated after seeing simple and obvious solutions like the above, but can never bring myself to code them as such.
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.
You are not mistaken, there is no chapter on functional programming. Why? Because "The Little Schemer" is a way better book for teaching better functional programming than I could possibly do in a Python book. Python's functional concepts are just not really that great, so I couldn't explain them very well.
If you're not teaching pythons functional concepts, then you're not teaching python.
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]
Python does functional programming without people even knowing that it is functional programming :)
While I do agree those principles are useful, I think introducing those topics would diverge the focus of the book. I think the goal was of introductory nature not comprehensiveness.
There are some great beginner's books out there that barely cover functional constructs (e.g. PragProg's 'Learn to Program'). But I have always felt that such an omission is really a bad mistake. map/fold/filter introduce two very important ideas:
- 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.
Sure, that's why Graham Hutton can do it in one chapter. Most books discuss lists and functions anyway, and from there is not such a big step to give an introduction to lambdas/closures, maps, folds, and filters.
It's not as if we are discussing monads (which are also easy to understand, given a good teacher).
Yeah. The argument is based on reduce not being clear and easy to understand, which is frustrating to those of us who actually find map/reduce/filter to be more clear, not less.
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)
Meh. I just sent this to a friend of mine that knows nothing about coding, but is taking a class (biology) that uses python. She really has no need of functional programming, she just needs to know how to survive her problem sets. I think that's the audience.
Exactly. I taught programming, not dogma. Frankly, if I can teach two paradigms, and one is easy to explain while the other is hard, well I'm going to teach the easy one to explain.
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.
Ditto for generators. In the process you could introduce pipelining and thus give a window into the Unix way which is probably pretty relevant for a newcomer. Or I've just been around too long to know what's relevant for a newcomer.
I really think it's acceptable to introduce these function to newbies, I'll go as far as saying it's actually a good thing.
I like the chapter on automated testing.