It's becoming more common to see "Functional Programming in X". Why don't we use functional languages like oCaml or Haskell more often? Are we making the jump in two steps instead of one? I've never written more than a few lines of either so I can't tell if something "better" is waiting for me in functional land.
Functional Programming in Python [pdf]
31–40 of 62 posts
Re: Functional Programming in Python [pdf]
#32It's becoming more common to see "Functional Programming in X". Why don't we use functional languages like oCaml or Haskell more often? Are we making the jump in two steps instead of one? I've never written more than a few lines of either so I can't tell if something "better" is waiting for me in functional land.
Re: Functional Programming in Python [pdf]
#33Funny how things turned out. I still remember this post[1], it was profoundly disappointing to see Guido's way of thinking. Much of the damage was reversed but it still left an indelible impression that there's a lack of vision for what's going to be important if the language is to stay relevant in the future. [1] http://www.artima.com/weblogs/viewpost.jsp?thread=98196
You may not agree with it, but it's a vision.
Re: Functional Programming in Python [pdf]
#34Yeah. Python has the functional programming features I expect of any modern language. However, I feel that Python has a lot of unneeded syntax. I always prefer apply() over * and map() and filter() over list comprehensions. func(*args) apply(func, args) [func(a) for a in collection] map(func, collection) [a for a in collection if func(a)] filter(func, collection) I don't see why people use all of this special syntax.
From other perceptive, these usually bother me when my functions are larger, and ideally functions should be small. So I take it as sign that I should probably break down my function.
And yeah, tail calls! I expect that from a modern language with functional programming features. Unfortunately it seems there are no plans to add them in Python
Re: Functional Programming in Python [pdf]
#35It's becoming more common to see "Functional Programming in X". Why don't we use functional languages like oCaml or Haskell more often? Are we making the jump in two steps instead of one? I've never written more than a few lines of either so I can't tell if something "better" is waiting for me in functional land.
Also missing is a way to select between strict or lazy evaluation.
Re: Functional Programming in Python [pdf]
#36It's becoming more common to see "Functional Programming in X". Why don't we use functional languages like oCaml or Haskell more often? Are we making the jump in two steps instead of one? I've never written more than a few lines of either so I can't tell if something "better" is waiting for me in functional land.
Probably because its easier to see the use of functional paradigms in languages you're familiar with. OCaml and Haskell are great languages, but they require a lot of new learning at once.
Re: Functional Programming in Python [pdf]
#37Nice, short little book! `compose` can be simpler: def compose(fn, *fns): def _composer(f, g): return lambda *args: f(g(*args)) return reduce(_composer, fns, fn) This little function is really, really cool because it allows you to build up more interesting functions by piecing together a bunch of small, useful ones. def upper(s): return s.upper() def exclaim(s): return s + '!' # instead of this really_angry = lambda…
For compose to really shine, you need to be able to curry/partially apply functions. This part of things is made much more difficult than necessary because of Python's unnecessarily neutered lambda syntax (in fact, I don't think one can claim that Python is FP friendly until this decision is corrected). It's also worth noting that reduce() was removed as a builtin for Python 3.
lambda x: f(y) + g(y) for y = expensive_computation(x)
In Python 3, `reduce` can be trivially imported from `functools`.Re: Functional Programming in Python [pdf]
#38Even knowing a lot about FP, I still found this worth skimming for the esoteric Python syntax. When it comes to constructing dictionaries with list comprehensions, I would always do something like this: dict([n, 2 ** n] for n in range(5)) But they pointed out an actual "dict comprehension" that I didn't even realize existed: { n: n ** 2 for n in range(5) } And there is a similar "set comprehension": { n ** 2 for n in…
This is part of the generalized comprehension syntax. You can also do lazy generator comprehensions. a = (i for i in range(10) if i % 2 == 0) print(list(a)) You can omit the parenthesis, and use them in calls which expect an iterable. b = max(i for i in range(0, 10) if i % 2 == 0) print(b)
Here's how you make those set/dict whatever comprehensions in Python 2.6, before the native syntax is used:
s = set(i for i in xrange(10) if not i%2)Re: Functional Programming in Python [pdf]
#39Earlier quoted context omitted.
This is part of the generalized comprehension syntax. You can also do lazy generator comprehensions. a = (i for i in range(10) if i % 2 == 0) print(list(a)) You can omit the parenthesis, and use them in calls which expect an iterable. b = max(i for i in range(0, 10) if i % 2 == 0) print(b)
It's not exactly the same, which is what I thought was interesting. My first example did use a generator expression inside the dict() constructor, but in that case you need to specify the key and value in a tuple or a list. With the dictionary comprehension you can just separate the key and value with a colon, which is more natural. It might just be sugar on top of a generator expression but it is definitely a specia…
s = {i**2 for i in range(10) if i}
and the colon is what makes the dict comprehension different from the set comprehension: d - {i:i**2 for i in range(10) if i}Re: Functional Programming in Python [pdf]
#40Earlier quoted context omitted.
This is part of the generalized comprehension syntax. You can also do lazy generator comprehensions. a = (i for i in range(10) if i % 2 == 0) print(list(a)) You can omit the parenthesis, and use them in calls which expect an iterable. b = max(i for i in range(0, 10) if i % 2 == 0) print(b)
Although Raymond Hettinger has also called them generator "comprehensions" in the early proposals, the current documentation calls them "generator expressions". And good examples. Here's how you make those set/dict whatever comprehensions in Python 2.6, before the native syntax is used: s = set(i for i in xrange(10) if not i%2)