Functional Programming in Python [pdf] • Hacker News Board

Re: Functional Programming in Python [pdf]

#21

Post by agentultra » Fri, Jul 24, 2015, 10:23 PM UTC

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 s: exclaim(exclaim(upper(s)))
    really_angry('napster bad') # NAPSTER BAD!!

    # we can do this
    really_angry = compose(upper, exclaim, exclaim)
    really_angry('fire good') # FIRE GOOD!!

    # and
    import operator as op
    from functools import partial as p
    max(map(compose(p(op.add, 1), p(op.mul, 3)), (1, 2, 3, 4)))

`compose` is a neat function and worth exploring. This is a cool book and I always hope Python gets more light shone on its FP-friendly features.

Re: Functional Programming in Python [pdf]

#22

Post by jshen » Fri, Jul 24, 2015, 10:48 PM UTC

RMarcus wrote: post #14

benkuykendall wrote: post #8

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.

In Python3, you are really looking at... (func(a) for a in collection) map(func, collection) as equivalent. If you want a list (and not a generator), you would need to do this: [func(a) for a in collection] list(map(func, collection)) For me, the first set (comprehensions) of notation has a more mathematical feel to it, i.e. { x^2 | x \in 0...10 }. Just replace the bar with "for" and it's almost the same thing. I bel…

I've always found the list comprehension harder to read for non trivial examples. It may just be a matter of which a person learned first.

Re: Functional Programming in Python [pdf]

#23

Post by svisser » Fri, Jul 24, 2015, 11:09 PM UTC

zepolud wrote: 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

Removing features does not mean there is a lack of vision.

The purpose of Python is not the same as, say, Haskell.

Design decisions should therefore be viewed as such - it's not about a steady increase of functional features and a decrease of procedural features.

Re: Functional Programming in Python [pdf]

#24

Post by dozzie » Fri, Jul 24, 2015, 11:18 PM UTC

jshen wrote: post #22

RMarcus wrote: post #14

Earlier quoted context omitted.

In Python3, you are really looking at... (func(a) for a in collection) map(func, collection) as equivalent. If you want a list (and not a generator), you would need to do this: [func(a) for a in collection] list(map(func, collection)) For me, the first set (comprehensions) of notation has a more mathematical feel to it, i.e. { x^2 | x \in 0...10 }. Just replace the bar with "for" and it's almost the same thing. I bel…

I've always found the list comprehension harder to read for non trivial examples. It may just be a matter of which a person learned first.

Not quite. I learned map and filter much earlier, and still I use more list comprehensions, both in Python and in Erlang.

Re: Functional Programming in Python [pdf]

#25

Post by m_mueller » Fri, Jul 24, 2015, 11:24 PM UTC

jshen wrote: post #22

RMarcus wrote: post #14

Earlier quoted context omitted.

In Python3, you are really looking at... (func(a) for a in collection) map(func, collection) as equivalent. If you want a list (and not a generator), you would need to do this: [func(a) for a in collection] list(map(func, collection)) For me, the first set (comprehensions) of notation has a more mathematical feel to it, i.e. { x^2 | x \in 0...10 }. Just replace the bar with "for" and it's almost the same thing. I bel…

I've always found the list comprehension harder to read for non trivial examples. It may just be a matter of which a person learned first.

> It may just be a matter of which a person learned first.

I think this is the case, for me map is much harder to read. But I also think that comprehensions go back to math sets, so I was familiar with this even before learning any programming. Therefore comprehensions clicked immediately for me and it's by far my favourite python feature.

Re: Functional Programming in Python [pdf]

#26

Post by Scramblejams » Fri, Jul 24, 2015, 11:37 PM UTC

fuzzythinker wrote: post #18

Use mochi if you really want to use FP in python. https://github.com/i2y/mochi

Interesting, thanks for the link. Do you know if it has any multicore (i.e. parallel) support? I looked but all I could see was support for concurrency.

Re: Functional Programming in Python [pdf]

#27

Post by hajile » Fri, Jul 24, 2015, 11:38 PM UTC

agentultra wrote: post #21

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.

Re: Functional Programming in Python [pdf]

#28

Post by hajile » Fri, Jul 24, 2015, 11:47 PM UTC

m_mueller wrote: post #25

jshen wrote: post #22

Earlier quoted context omitted.

I've always found the list comprehension harder to read for non trivial examples. It may just be a matter of which a person learned first.

> It may just be a matter of which a person learned first. I think this is the case, for me map is much harder to read. But I also think that comprehensions go back to math sets, so I was familiar with this even before learning any programming. Therefore comprehensions clicked immediately for me and it's by far my favourite python feature.

I learned both around the same time, but even in good functional languages like Haskell, using a comprehension for anything more than simple problems results in an unreadable mess.

map or filter are much easier to read for complex data manipulations and as a bonus, their composition rules make it easy to increase performance. For example, if you see two map functions together, you can wrap them in a compose and only map over your elements once. This isn't as immediately obvious when you're using comprehensions.

Re: Functional Programming in Python [pdf]

#29

Post by fuzzythinker » Fri, Jul 24, 2015, 11:54 PM UTC

Scramblejams wrote: post #26

fuzzythinker wrote: post #18

Use mochi if you really want to use FP in python. https://github.com/i2y/mochi

Interesting, thanks for the link. Do you know if it has any multicore (i.e. parallel) support? I looked but all I could see was support for concurrency.

For parallel programming, you need either:

https://docs.python.org/dev/library/multiprocessing.html#mod...

or

http://www.parallelpython.com/

or use the GPU using many available libraries.

Re: Functional Programming in Python [pdf]

#30

Post by melling » Fri, Jul 24, 2015, 11:56 PM UTC

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.