Live data from Hacker News

Functional Programming in Python [pdf]

oreilly.com

31–40 of 62 posts

Re: Functional Programming in Python [pdf]

#31
post #30

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.

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]

#32
post #30

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.

There are many steps between functional programming in, say, Python, and writing everything in Haskell. Many differences. Not everybody has the same opinion of all those differences.

Re: Functional Programming in Python [pdf]

#33
post #10

Funny 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

There should be one -- and preferably only one -- obvious way to do it. [1]

You may not agree with it, but it's a vision.

[1] https://www.python.org/dev/peps/pep-0020/

Re: Functional Programming in Python [pdf]

#34

Yeah. 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.

Part that bothers me about Python is no special binding form, that is you could just do x = 3 to add x variable to my environment, and second is not-strict lexical scoping.

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]

#35
post #30

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.

I'm often missing a feature to make language X act in a purely functional way (i.e., to disable side effects completely in a relevant part of the code).

Also missing is a way to select between strict or lazy evaluation.

Re: Functional Programming in Python [pdf]

#36
post #30

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.

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.

You are right about it being nice to see functional code in your language. However, from my learning experience I understood the functional style much better by using actual functional language. I started with Scheme which has very minimal easy to understand syntax. Many courses ask students to try forget whatever they know about programming before introducing functional style. If that helps (for me it did), I think starting with new language would be nice decision.

Re: Functional Programming in Python [pdf]

#37
post #27

Nice, 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.

I'd love let-like syntax in lambdas, something along the lines of

    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]

#38

Even 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)

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)

Re: Functional Programming in Python [pdf]

#39

Earlier 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…

Yes, in Python 2.7 onward:

  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]

#40

Earlier 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)

Seems like a comprehension is just a particular form of Python expression.
Post reply on HN