Live data from Hacker News

Functional programming in Python

docs.python.org

61–64 of 64 posts

Re: Functional programming in Python

#61

One thing that's been key for me is namedtuple (in the collections module). It's immutable like a tuple, but the values can be accessed by name just as if they were object attributes built with the class keyword. It's great for creating generic functions (think Lisp and CLOS) instead of using Python's prototypical system. And since tuples can contain any objects and functions are objects, you can bind callables like…

namedtuple is awesome, until you realise it works internally by using eval and generating the source code of a class.

See also http://bugs.python.org/issue3974, where someone submits a patch for namedtuple that doesn't use exec. The maintainers reject it as less clear and probably slower. I agree there is "nothing unholy in using exec", though I found this weird at first too.

Re: Functional programming in Python

#62
post #60

Earlier quoted context omitted.

I doubt you'll see that - at least in CPython. Guido's been very clear about how he feels about implementing functional paradigms in Python, so it will probably never support functional programming in the standard implementation - just a bit in syntax/interface.

I honestly don't understand that. Data structures are just code ... isn't it much more work to change syntax and interfaces instead of adding some decent implementations of data structures to the library?

The syntax changes happened very much against Guido's will - he actively tried to remove lambda (and I believe map as well) for quite a while.

Anyone can write whatever Python libraries they want, but I doubt anything of the sort would be added to the standard library, and certainly nothing that would require an FP-aware interpreter to optimize in a useful way.

Re: Functional programming in Python

#63
post #53

Earlier quoted context omitted.

> There's no in-place map It's not a matter of in-place mapping, but if I remember correctly, map() returns a generator in Python3, which has the effect of simulating single-traversal and lazy evaluation like Haskell does. > mutability is a property of data-structures, not of functions True, but in a (purely) functional language, if all data structures are immutable and functions are simply mappings of input values t…

If Python were a non-functional language, as you claim, it wouldn't have map reduce and functools. Python is not a purely functional language, it is a multi paradigm language. This difference is the main point here.

No, that would go against the philosophy of Python: only one [obvious] way to do it. Lambda, map, and reduce were all components that Guido very much wanted to remove, as he felt they had no place in Python.

Python is an object-oriented language, and the fact that it is a more purely object oriented language than (for example) Java allows one to use functions as first-class objects in ways that appear to be consistent with a functional paradigm, but that doesn't mean that the language supports a functional approach. That would require support by the interpreter for some key

Put another way, what's the difference between the following?

> [f(x) for x in xrange(10)]

> map(f, range(10))

Without knowing the difference in the underlying implementation, you can't really be sure - it's possible that map() is just a syntactic alternative to a list comprehension, and you could write an implementation of Python that did just that. If we're talking about CPython, though (which we are), then we have to know that the latter is using a function object that is retrieved once and called multiple times, and the former is using a function object that is retrieved ten times. In the latter case, we have a function object that contains a bound method which receives the implicit parameter 'self' and an integer within the range specified, and this method call is what is, in idiomatic Python, producing the values that are then used to create the list. Also, xrange is using a generator, which requires several function calls in itself, whereas range creates a list (which is handled differently).

That isn't necessarily so inconsistent with a functional paradigm, but my point is that the implementation is more important than the function names - simply saying that map() and reduce() exist doesn't mean that Python is a multiparadigm language. Python is incredibly eager-evaluating and it does not optimize tail recursion, two things which make it hard to argue that Python supports a truly functional style.

As noted by another commenter, this is not an accident; while you can fake functional paradigms syntactically with Python's extensive implementation of first-class objects (including functions), the explicit goal is to discourage use of recursion, as well as other functional ways of thinking, in favor of iteration, and other imperative/OO ways of thinking.

Re: Functional programming in Python

#64
post #37

Earlier quoted context omitted.

There are situations where balanced search trees are appropriate. A general purpose priority queue (with delete and decrease-key operations); there's actually code for this in the _documentation_ of the heapq module; this seems really odd to me, why not just include it? It's also a shame that heapq is built on list instead of being a first-class data-structure, it feels bolted-on. Bitwise tries would be nice as well.

Even if heaps were a first class data-structures wouldn't the choice between trees and lists exist in the underlying implementation? Ultimately you would have to allow for both or deal with the strengths and weaknesses of that implementation.

As far as I know array-based heaps are most efficient with practical workloads (because it doesn't have the overhead & non-locality due to pointers for a tree structure). I don't think it's necessary to offer multiple implementations, just as there is only a single well tuned hash table in Python. What matters is that the functionality of an abstract data type is offered.
Post reply on HN