Why functional Python matters

[Alexander Schmolck]

Dave Benjamin <ramen at lackingtalent.com> writes:

> The next thing I read will probably not surprise you if you have ever done a
> Google search on functional programming. It was David Mertz's "Charming
> Python" series on IBM's DeveloperWorks. His papers were not easy to digest
> in one sitting, but I made a great effort to understand them and apply the
> techniques he described. At this point, I should mention that I was still
> programming only in PHP!

I think your life might be much happier if you just went to
http://www.drscheme.org/, dowloaded Dr Scheme and used *that* for
webdevelopment. Then you can use a real functional programming language and
read books by people who actually have a real clue about functional
programming (there is lots of *excellent* material available on-line and for
free, like SICP and HTDP, the latter uses Dr Scheme -- also have a look at
http://www.cs.brown.edu/courses/cs173/2001/Lectures/). Why settle for some
second-rate immitation? [1]

(Dr Scheme *does* have web libraries, I've never used them but I'd suspect
they shouldn't be too bad, because they seem to have hit on trick of using
webdevelopment as application domain to bring things like continuations to the
unwashed masses (viz. their sophomores) :).

>    - lambda
>    
>    Lambda has had the thorniest history of all of these, I think. Lambda has
> its roots in LISP and the Lambda calculus, and can be used to create
> "anonymous functions" at runtime that can be passed around as needed. This
> is a very powerful and useful feature for functional programming, as well as
> for event-driven programming. It baffles me that anyone would want to remove
> it.

Ain't gonna happen. Anyway you can always replace 

  foo(lambda x: x+3)
with: 
  def bar(x): return x + 3
  foo(bar)

 
> keyword-argument trick wasn't really that bad, once you got used to it. In
> any case, with dynamic scoping, this problem has completely disappeared.
                 ^^^^^^^^^^^^^^^
not quite.


> The second "problem" that everyone seems to keep bringing up is that lambda
> limits you to expressions, not statements. This makes me laugh every time,
> because this is one of the things that I *loved* about Python when I was
> first learning it! If you get used to writing functions that only return
> expressions, you are on the road to understanding the functional style! One

Only that python won't let you use rather helpful things like ``if`` as
an expression, but never mind.

> In fact, I believe that it is advantageous to design functions specifically
> for use with map and filter. If you design this way, you will benefit from
> cleaner syntax than list comprehensions can offer. For example:

I wonder how a function written for map would look different from one written
for a list comprehension...

> Rather than remove these important functional built-ins, I would like to see
> two last built-ins be added: unzip (to reverse the behavior of zip), and

There is already an unzip function and it's written ``zip(*...)``

> curry (see the example by Alex Martelli, et. al. in the Python Cookbook,

Why not just use lambda? Python's argument passing is fairly complex, so I'm
not sure whether one (or rather two) curry function(s) would be worth the pain
(at least not if you tell your emacs to display lambda as greek character).

'as

Footnotes: 
[1]  I'm talking about *functional* programming.