

Functional programming in Python - plessthanpt05
http://docs.python.org/release/3.1.5/howto/functional.html

======
dustingetz
as has been pointed out, python isn't particularly great at doing hardcore
functional programming due to lack of native persistant datastructures.
however i've found it great for learning functional programming without having
to get used to the syntax of real functional languages.

here are some different ways to implement functional sequence operations
without native python syntax like `yield`:

[https://github.com/dustingetz/sandbox/blob/master/etc/lazy.p...](https://github.com/dustingetz/sandbox/blob/master/etc/lazy.py)
<https://github.com/dustingetz/sandbox/blob/master/etc/map.py>

and an unfinished, sloppy impl of monads in python with lots of minor errors:

[http://www.dustingetz.com/2012/04/07/dustins-awesome-
monad-t...](http://www.dustingetz.com/2012/04/07/dustins-awesome-monad-
tutorial-for-humans-in-python.html)

~~~
SiVal
I was at a Python user group meeting with Guido a few years back, and I asked
him about his plans for functional programming support in Python. He responded
that he thought functional programming was a lot less useful than all the hype
would suggest, and that, far from planning more support for functional
programming, he regretted having put in as much support as he already had.
Ideally, he said, he would remove things like lambda instead of making them
stronger.

Even things like tail call elimination, he said, would just encourage people
to use more recursion, when iteration was easier to read, and in places where
TCE would work, the programmer could obviously convert it to iteration himself
and should do so for code clarity.

I like Python, and I like a lot of things about functional programming, so it
wasn't the answer I was hoping for. Unless Guido has had a change of heart
since then, I wouldn't pin my hopes on Python ever becoming a first-rate
functional programming language. It's first rate at the things Guido values.

~~~
ericmoritz
I wish he would add TCE for the sole fact that parsing tree like structures
feels much more natural using recursion than it does with a for loop. I am
always paranoid that a really deep structure will cause an stack depth
exceeded exception.

There's a quote from Guido about private attribute access where he said,
"We're all adults", and that leaving the open is beneficial.

Recursion is another tool that he should let us adults use if it solves a
problem better and TCE is lovely feature to have. Frankly, if you're using
recursion, you either just learned it in a CompSci class or you know what
you're doing. Either way, daddy Guido shouldn't tell us no :).

~~~
lucian1900
You can use an explicit trampoline to make sure you don't block the stack.
It's not as clean, but still better than loops.

------
theorique
This is a useful reference but not really all that current. It dates back to
2006 - the functional constructs in Python now have evolved and changed over
the years.

------
pepijndevos
What is really missing is a set of decent data structures.

~~~
jlarocco
What do you mean? What would you add on top of the built-ins and stdlib data
structures?

~~~
swannodette
I believe he is talking about persistent data structures.

~~~
roryokane
Link for convenience: <http://en.wikipedia.org/wiki/Persistent_data_structure>

“… a persistent data structure is a data structure that always preserves the
previous version of itself when it is modified. Such data structures are
effectively immutable, as their operations do not (visibly) update the
structure in-place, but instead always yield a new updated structure.”

------
chimeracoder
One thing that's been key for me is namedtuple (in the collections module).
It's immutable like a tuple, but the values can be accessed by name just as if
they were object attributes built with the class keyword. It's great for
creating generic functions (think Lisp and CLOS) instead of using Python's
prototypical system. And since tuples can contain any objects and functions
are objects, you can bind callables like lambdas to those names, which allows
you to have 'methods' if you want as well.

That said, the standard library leaves something to be desired for the
functional style. It makes sense for object-oriented programming to have non-
mutating functions return the result and mutating functions return None (think
sorted vs. sort), but this can get rather irritating when you're trying to
write in a purely functional paradigm.

Also, am I forgetting my Python, or does it not have a great solution for
appending to the front of a list? One thing I _love_ about Lisp is that it's
ridiculously easy to write (cons item some-list), or even (cons item1 (cons
item2 some-list)). Doing the same thing in Python is irritating, because
insert() doesn't return the result list.

...or maybe that's what I deserve for trying to write Lisp-like code in
Python, anyway....!

EDIT: As noted in the comments, the '+' operator will suffice here. Though
since lists are really arrays and not linked lists, this functional way of
thinking will result in horribly inefficient CPython code.

~~~
TazeTSchnitzel
namedtuple is awesome, until you realise it works internally by using eval and
generating the source code of a class.

~~~
benhoyt
See also <http://bugs.python.org/issue3974>, where someone submits a patch for
namedtuple that doesn't use exec. The maintainers reject it as less clear and
probably slower. I agree there is "nothing unholy in using exec", though I
found this weird at first too.

