Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Functional programming with Python

ua.pycon.org

Post reply on HN
Print view View original

11–20 of 51 posts

Re: Functional programming with Python

#11

Post by boothead »

dustingetz wrote: post #8

i started learning functional programming with python, it falls apart at ~300 loc which is absurdly low, which makes python basically useless for production FP. python's data structures are mutable, and mutable data structures necessarily expose a different interface than immutable data structures. using mutable datastructures in immutable style necessarily has severe performance penalties; and to do meaningful stuff…

I agree. I've written a fair bit of python and I lean fairly far towards the FP style. However it feels like ice skating uphill compared to using a language that has FP baked in.

Re: Functional programming with Python

#12

Post by apendleton »

aschwo wrote: post #5

I'm curious, on the Currying (Standard Library) slide, the author uses `attrgetter` from the `operator` module -- I've always used `getattr` to achieve the same thing. Am I missing something by not using `attrgetter`?

attrgetter takes an attribute name and returns a function that, when passed an object, returns that attribute from that object. So it's a curried getattr. These are equivalent:

f = attrgetter("some_property")

f = lambda obj: getattr(obj, "some_property")

Re: Functional programming with Python

#13

Post by Gakusei »

Great job (some ruby code comparisons would have been welcomed, though).

A little mistake on page 48: the Clojure code will fail. Use (map #(* % 2) '(1 2 3)) or (map (partial * 2) '(1 2 3)) instead of: (map #(%*2) '(1 2 3))

Re: Functional programming with Python

#14

Post by koenigdavidmj »

samdk wrote: post #7
jewbacca wrote: post #6

Earlier quoted context omitted.

I don't know if this is a problem if you're going hardcore with your FP -- one line is one expression, and multiple expressions are probably going to be stateful, which should probably be factored out into something with a name. In Haskell, the only places (that occur to me right now) where you'll have multiple lines are: * Pattern matching function arguments * Giving things names with `let` or `where` * In a monadic…

...or anywhere you're using a 'let' statement. I write a lot of OCaml, and I write a lot of multi-line anonymous functions that aren't stateful. I think it's less common to do this in Haskell, but that's more because it's Haskell than because there aren't any side effects. Random other tidbit that doesn't deserve its own comment: In Python, instance.method is the same as doing ClassName.method(instance). This can be…

Or you can do operator.methodgetter("method") and not need to know the class name.

Re: Functional programming with Python

#15

Post by icebraining »

vsbuffalo wrote: post #9
beambot wrote: post #4

Forgot one big con: Python lambda functions aren't "proper" functions (ie. arbitrary multi-line code blocks). Guido van Rossum has addressed this many times, saying (in effect) "it adds undue complexity and would be un-Pythonic", eg: http://www.artima.com/weblogs/viewpost.jsp?thread=147358 This is one of my (very few!) gripes with FP in Python.

And you can't pass them as simple functions to do stuff via the multiprocessing module because they can't be pickled. I don't understand this infatuation with FP in Python. To me the essence of functional programming is immutable state. Python has mutable state to the core. List comprehensions are novel syntax for many FP-esque operations (so much so that map, reduce, & filter were almost removed from Python at some…

You could always use tuples; they're essentially immutable lists.

  >>> a = tuple(3*x for x in range(5))
  >>> a[2]
  6
  >>> map(lambda x: str(x), a) #can be iterated
  ['0', '3', '6', '9', '12']
  >>> a[2] = 9
  TypeError: 'tuple' object does not support item assignment
  >>> a.pop()
  AttributeError: 'tuple' object has no attribute 'pop'

Re: Functional programming with Python

#16

Post by ericmoritz »

Great slides. I've been toying casually with a FP project for Python. It's an attempt to bring common FP abstractions and lazy evaluation of sequences using generators.

It's a work in progress, and I often think to myself, "Is this a good idea".

Here's the latest iteration: I'm in the middle of documenting things for an alpha release: https://github.com/ericmoritz/fp/blob/feature/documentation/...

Re: Functional programming with Python

#17

Post by jewbacca »

jewbacca wrote: post #6
beambot wrote: post #4

Forgot one big con: Python lambda functions aren't "proper" functions (ie. arbitrary multi-line code blocks). Guido van Rossum has addressed this many times, saying (in effect) "it adds undue complexity and would be un-Pythonic", eg: http://www.artima.com/weblogs/viewpost.jsp?thread=147358 This is one of my (very few!) gripes with FP in Python.

I don't know if this is a problem if you're going hardcore with your FP -- one line is one expression, and multiple expressions are probably going to be stateful, which should probably be factored out into something with a name. In Haskell, the only places (that occur to me right now) where you'll have multiple lines are: * Pattern matching function arguments * Giving things names with `let` or `where` * In a monadic…

NOTE: Ooops, it seems the 'edit' window expired on my comment. Expanding, unfortunately, in a separate comment:

----

I don't know if this is a problem if you're going hardcore with your FP. When we're talking about "lines" in Python, one line is exactly one statement, and if you're doing FP, that statement is an expression. Multiple statements are going to be either stateful, or declaring a temporary name for an intermediate value.

I am probably not being sufficiently imaginative right now, but I can't think of any fully-fledged functional pattern which would require multiple statements in a lambda, which would not be better abstracted out and given a name, and I would genuinely like to hear some examples of cases where a multi-statement lambda make for "better" code (or to hear how my presentation of this problem might be flawed, because I haven't done any serious Python programming recently enough to be very close to the issue).

----

In Haskell, a language where the syntax has been exhaustively designed to facilitate FP, the only places where you'll see multiple lines (I'm pretty sure this is exhaustive, without using GHC extensions, eg. Arrow `proc` blocks) are:

* Pattern matching function arguments

* Giving things names with `let` or `where`

* In a monadic `do` block -- which is just sugar that reduces to single-expression chain of lambdas, and are not equivalent to multi-statement lambdas

Re: Functional programming with Python

#18

Post by haldean »

Note that `reduce` has been, if not deprecated, then at least discouraged (not that I agree with this, but reduce gets taken away in Python 3, so it's probably good form to stop using it). The author does `reduce(operators.add, lst)` a lot; you can do that using `sum(lst)` instead.

Re: Functional programming with Python

#19

Post by mh- »

dustingetz wrote: post #8

i started learning functional programming with python, it falls apart at ~300 loc which is absurdly low, which makes python basically useless for production FP. python's data structures are mutable, and mutable data structures necessarily expose a different interface than immutable data structures. using mutable datastructures in immutable style necessarily has severe performance penalties; and to do meaningful stuff…

why doesn't your blog have an RSS feed?

Re: Functional programming with Python

#20

Post by vsbuffalo »

icebraining wrote: post #15
vsbuffalo wrote: post #9

Earlier quoted context omitted.

And you can't pass them as simple functions to do stuff via the multiprocessing module because they can't be pickled. I don't understand this infatuation with FP in Python. To me the essence of functional programming is immutable state. Python has mutable state to the core. List comprehensions are novel syntax for many FP-esque operations (so much so that map, reduce, & filter were almost removed from Python at some…

You could always use tuples; they're essentially immutable lists. >>> a = tuple(3*x for x in range(5)) >>> a[2] 6 >>> map(lambda x: str(x), a) #can be iterated ['0', '3', '6', '9', '12'] >>> a[2] = 9 TypeError: 'tuple' object does not support item assignment >>> a.pop() AttributeError: 'tuple' object has no attribute 'pop'

Yea, but still gross. map() isn't even an endomorphism.
Post reply on HN