Functional Programming in Python [pdf] • Hacker News Board

Re: Functional Programming in Python [pdf]

#41

Post by aaronchall » Sat, Jul 25, 2015, 2:00 AM UTC

rectangletangle wrote: post #13

tromp wrote: post #2

https://en.wikipedia.org/wiki/Python_Bridge "Python Bridge, officially known as High Bridge, is a bridge that spans the canal between Sporenburg and Borneo Island in Eastern Docklands, Amsterdam. It was built in 2001 and won the International Footbridge Award in 2002. The bright red bridge spans 90 meters and was designed by Adriaan Geuze of the architectural firm West 8" Coincidentally, Amsterdam can be considered t…

This reads like Lisp.

Yes it's quite possible to write obfuscated Python. See the docs:

https://docs.python.org/2/faq/programming.html#is-it-possibl...

Re: Functional Programming in Python [pdf]

#42

Post by GFK_of_xmaspast » Sat, Jul 25, 2015, 2:14 AM 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

I remember seeing that post and having it be the first time I thought "huh, does van Rossum know what he's doing" but it certainly wasn't the last.

Re: Functional Programming in Python [pdf]

#43

Post by GFK_of_xmaspast » Sat, Jul 25, 2015, 2:17 AM UTC

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.

If you don't have the function handy and don't want to go thru the effort of making a lambda, list (set, dictionary, generator) comprehensions can be more convenient (and you can comprehend over nested lists too)

Re: Functional Programming in Python [pdf]

#44

Post by m_mueller » Sat, Jul 25, 2015, 2:43 AM UTC

hajile wrote: post #28

m_mueller wrote: post #25

Earlier quoted context omitted.

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

Could you give an example?

Do you mean something like

> [ manager.name for manager in set([ person.manager for person in employees ])]

?

I assume with something like set() or unique() you need to create the intermediate iterable anyway, but without it I have trouble finding an example where doing a single list comprehension wouldn't suffice.

Re: Functional Programming in Python [pdf]

#45

Post by ubernostrum » Sat, Jul 25, 2015, 2:57 AM UTC

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.

I don't see why people use all of this special syntax.

Comprehensions are one fairly easy way of thinking about sets of things, and transformations of those sets of things. It may not be your preferred way to think about them, but that doesn't mean it's unneeded or that people are wrong to prefer another way.

Re: Functional Programming in Python [pdf]

#46

Post by pdonis » Sat, Jul 25, 2015, 3:20 AM UTC

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.

> I don't see why people use all of this special syntax.

(1) It's easier to read, particularly for people who don't always think in terms of functional programming.

(2) It's faster, particularly if you have to construct a lambda for the function in apply, map, or filter.

Re: Functional Programming in Python [pdf]

#47

Post by jimbokun » Sat, Jul 25, 2015, 3:54 AM UTC

melling wrote: 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 made this comment earlier today about Elixir being more approachable for people coming from another dynamic language:

https://news.ycombinator.com/item?id=9942407

Re: Functional Programming in Python [pdf]

#48

Post by aaronchall » Sat, Jul 25, 2015, 5:26 AM UTC

rectangletangle wrote: post #40

aaronchall wrote: post #38

Earlier quoted context omitted.

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.

Here's the grammar file: https://docs.python.org/2/reference/grammar.html

Look for dictorsetmaker (for {}) testlist_comp (for generator expressions) and listmaker (for [], i.e. list comprehensions).

Re: Functional Programming in Python [pdf]

#49

Post by gamegoblin » Sat, Jul 25, 2015, 5:29 AM UTC

hajile wrote: post #27

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.

It's possible to hack currying into python with a decorator like:

https://gist.github.com/grantslatton/9221084

(I made this for fun, use at your own risk)

Re: Functional Programming in Python [pdf]

#50

Post by gamegoblin » Sat, Jul 25, 2015, 5:31 AM UTC

nine_k wrote: post #37

hajile wrote: post #27

Earlier quoted context omitted.

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

The ugly hack around this would be

    lambda x: (lambda y: f(y) + g(y))(expensive_computation(x))