Origins of Python's “Functional” Features (2009)

http://python-history.blogspot.com/2009/04/origins-of-pythons-functional-features.html

by tosh • 10 years ago

127 34 10 years ago

python-history.blogspot.com

StClaire• 10 years ago

I love the functional aspects of Python. It's nice to break the monotony of loops every once and while.

Alex39172• 10 years ago

I dunno. I love the functional parts of Groovy. But with Python I generally only break out the functional stuff when it's a choice between one unreadable line of code with a comment or else six unreadable lines of code. (E.g. when parsing an API response with weird and arbitrary nesting.)

foota• 10 years ago

Which is supposed to be functional in that example?

tommikaikkonen2• 10 years ago

While it's far from a functional language, I find that it's possible to build functional style abstractions without too much headache. The iterator protocol is so well supported by the language and the standard libraries that using map, filter, itertools, generator expressions & comprehensions gets you a long way. You get the rest of the way by writing any specialized combinators you need and then imperative code to tie things together. You can build up a lazy pipeline of data transformations that works pretty well.

There are some gotchas where you need to explicitly copy (itertools.tee) iterators when you have multiple consumers, and be careful with mutable values, but it's manageable.

It would be nice to use curried functions as functools.partial gets verbose, but at that point you're far from Pythonic code.

maweki• 10 years ago

The state of a generator is always a problem that trips me up the most when I try to do FP-Python. In general a function shouldn't care whether the input was a list, set or generator. While iterating over it (or yielding from it), we always mutate some internal state of the iterator.

One solution would be, I think, to always pass tee-d copies of iterators and never(!) any iterator like it is (because you don't know whether next() has side effects or not). The other solution would be to not ever do anything lazy. One could also always consume all iterators fully. That way any generator re-use would be apparent immediately.

Some function that moves a generator forward just one or two items (something with the semantics of findFirst, for example), can subtly introduce bugs.

xapata2• 10 years ago

Make your functions consumers. Don't pass tee'd iterators in, but tee after receiving if necessary.

I don't see how find_first would cause any more problems than filter or sum.

marcosdumay• 10 years ago

Personally, I run by a rule that I must consume a generator on the same line it is created, otherwise I use something that isn't lazy.

If you get some huge collection to scan, or wants to sync your code by sharing an iterator internal state, you may want to break that rule. But they are just too troublesome for my taste.

jgroszko• 10 years ago

Are there any public code bases out there that use this? Would be cool to see what sort of pipelines like this people are building and how they get used.

fermigier• 10 years ago

I have started a few weeks ago an index of useful resources (docs and code) related to functional programming in Python:

https://github.com/sfermigier/awesome-functional-python

I'm going to include this blog post as well.

Pull requests are welcome, BTW.

mangecoeur• 10 years ago

I have sometimes wondered why python used 'lambda' for anonymous functions rather than just... well literally anonymous function - normal function syntax without the name. Could have been something like

`def (x,y): x+y`

This makes it sound like that was just how it was implemented. Nothing fundamentally wrong with lambda i guess

pyre• 10 years ago

It's because lambda technically isn't an anonymous function. It's more like an anonymous expression. It probably helps to avoid confusion for people trying to do things that can't be expressions in it. E.g.:

    def (x,y): x += y

nerdponx• 10 years ago

I suspect this is because

    def f(x, y): x+y

is valid one-line syntax for a regular function definition (that in this case computes `x+y` and returns `None` becaus Python does not have implicit returns). Maybe the parser could distinguish between them by saying that "if the function definition is all on one line and the function is missing its name, it's a lambda":

    def f(x,y): return x+y
    g = def x,y: x+y
    assert f(3,4) == g(3,4)
    assert f != g

 That said I have no

Nothing gives me the willies in mathematical code like writing out Greek letters. I don't know why, it just does. The fact that the otherwise excellent Stan (https://mc-stan.org) only accepts ASCII variable names is depressing. I would love to be able to actually write `map(λ x: x+7, range(5))`. I think a big reason why people don't use `map`/`reduce`/etc. more is that writing anonymous functions is still verbose (`lambda` is just too long a word) and relatively hard to read compared to list comprehension. Better still a syntax like `x -> x+7` would be ideal, since I'm pretty sure `->` would be a unique syntax element.

wheaties• 10 years ago

I never understood his desire to remove 'reduce' from Python. I would love to hear a cogent reason as to why we should have to write a for-loop for everything 'reduce' like. In other languages, 'reduce' (akin to 'fold' for non-Python people) is one of the things you reach for daily.

empath75• 10 years ago

`from functools import reduce`

d0mine• 10 years ago

It is still available as functools.reduce

An explicit loop is easier to read as a rule than the corresponding reduce() code. See http://stackoverflow.com/questions/15995/useful-code-which-u...

jghn• 10 years ago

"Easier to read" for some people, I think you mean

talideon• 10 years ago

The main issue is syntactic: Python's syntax is such that reduce() isn't terribly useful. If Python had an equivalent of blocks in Ruby or at least the ability to write non-trivial lambdas, I can see reduce() being useful, but as things stand, it's just kind of useless.

Origins of Python's “Functional” Features (2009)

Related Stories