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

Charming Python: Functional programming in Python

ibm.com

Post reply on HN
Print view View original

21–26 of 26 posts

Re: Charming Python: Functional programming in Python

#21

Post by Swizec »

tmoertel wrote: post #16
Swizec wrote: post #11

Earlier quoted context omitted.

Usually list comprehensions are a much cleaner way to write a map. This I love. Personally what I love most about using more functional code aren't the clever lambda's and stuff, I actually try to avoid that because it looks weird in Python. What's really awesome is enclosing named functions inside bigger functions and using closures. The result is code where: 1. nobody can, by accident or intentionally, use inner fu…

> Usually list comprehensions are a much cleaner way to write a map. But the first makes my intent clearer than the second: map(f, xs) [f(x) for x in xs] In Python, where creating anonymous functions is syntactically expensive, list-comprehension syntax may be cheaper in many cases, but it's not clearer. When I want to map or filter something, I want to _say_ that I'm mapping or filtering, not explain to Python how t…

That depends. When you're doing simple translations the list way is much cleaner.

   ids = [item.id for item in all_items]
Seems much cleaner than

   ids = map(lambda item: item.id, all_items)
But yes, I agree, when you have to actually perform some less-than-trivial computation on every item of a list, map is much cleaner.

Re: Charming Python: Functional programming in Python

#22

Post by yason »

gcr wrote: post #14

This article was written in 2001, and python now includes first-class constructs for many of these. Map: >>> [ord(char) for char in "Hello"] [72, 101, 108, 108, 111] Filter: >>> [x for x in xrange(10) if x % 2] [1, 3, 5, 7, 9] For laziness, use parenthesis to turn the above list comprehensions into a generator comprehension. Though I don't demonstrate it, you can work over infinite sequences of objects this way with…

The functions are more first-class than list comprehensions and other syntactic alternatives. It's easier, both conceptually and lexically, to mangle, pass around, chain, and combine functions and function argument than it is to write nested list comprehensions.

Not against list comprehensions per se, really. They're just a convenient subset for most commonly idiomatic sequence-mangling-spells, but that's most of what they're good for.

Re: Charming Python: Functional programming in Python

#23

Post by [deleted] »

gcr wrote: post #14

This article was written in 2001, and python now includes first-class constructs for many of these. Map: >>> [ord(char) for char in "Hello"] [72, 101, 108, 108, 111] Filter: >>> [x for x in xrange(10) if x % 2] [1, 3, 5, 7, 9] For laziness, use parenthesis to turn the above list comprehensions into a generator comprehension. Though I don't demonstrate it, you can work over infinite sequences of objects this way with…

[deleted]

Re: Charming Python: Functional programming in Python

#25

Post by tmoertel »

Swizec wrote: post #21
tmoertel wrote: post #16

Earlier quoted context omitted.

> Usually list comprehensions are a much cleaner way to write a map. But the first makes my intent clearer than the second: map(f, xs) [f(x) for x in xs] In Python, where creating anonymous functions is syntactically expensive, list-comprehension syntax may be cheaper in many cases, but it's not clearer. When I want to map or filter something, I want to _say_ that I'm mapping or filtering, not explain to Python how t…

That depends. When you're doing simple translations the list way is much cleaner. ids = [item.id for item in all_items] Seems much cleaner than ids = map(lambda item: item.id, all_items) But yes, I agree, when you have to actually perform some less-than-trivial computation on every item of a list, map is much cleaner.

But the first of your examples is cleaner not because of any inherent advantage of list-comprehension syntax but because in Python the syntactic cost of turning an expression into an anonymous function is so high. In other words, you're comparing (cognitive cost of comprehension + low cost of expression) against (cognitive cost of map + high cost of promoting an expression to an anonymous function).

Don't blame map for Python's tax on expression-promotion. ;-)

Re: Charming Python: Functional programming in Python

#26

Post by tmoertel »

markmark wrote: post #20
tmoertel wrote: post #16

Earlier quoted context omitted.

> Usually list comprehensions are a much cleaner way to write a map. But the first makes my intent clearer than the second: map(f, xs) [f(x) for x in xs] In Python, where creating anonymous functions is syntactically expensive, list-comprehension syntax may be cheaper in many cases, but it's not clearer. When I want to map or filter something, I want to _say_ that I'm mapping or filtering, not explain to Python how t…

>But the first makes my intent clearer than the second That is entirely a matter of opinion. I would say python programmers with no functional background would find the list comprehension clearer, because that is the idiomatic python way. May would have no idea what map even does without looking it up on the net.

> That is entirely a matter of opinion.

It isn't entirely a matter of opinion, is it? When you use map to do your mapping, aren't you are stating your intent in the language of the profession? The name of the function, after all, is "map," and isn't this term's meaning rather firmly established in mathematics and computer science? So, the idea of calling a map a map has some precedent that we can use to justify the practice, doesn't it?

Now, if your audience has no notion of what a mapping is, then, yes, there's a level of semantic intent that you're not going to be able to communicate to them. (At least until they learn the concept; it's common, worth learning, and not hard to grasp.) But that doesn't mean that you should refuse to call an important concept by its established name.

Concepts, after all, earn their names for a reason. If a concept has one, it's probably best to use it.

Post reply on HN