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

Functional programming in Python

docs.python.org

Post reply on HN
Print view View original

51–60 of 64 posts

Re: Functional programming in Python

#51

Post by olavk »

SiVal wrote: post #41
dustingetz wrote: post #21

as has been pointed out, python isn't particularly great at doing hardcore functional programming due to lack of native persistant datastructures. however i've found it great for learning functional programming without having to get used to the syntax of real functional languages. here are some different ways to implement functional sequence operations without native python syntax like `yield`: https://github.com/dus…

I was at a Python user group meeting with Guido a few years back, and I asked him about his plans for functional programming support in Python. He responded that he thought functional programming was a lot less useful than all the hype would suggest, and that, far from planning more support for functional programming, he regretted having put in as much support as he already had. Ideally, he said, he would remove thin…

Python has added list and set comprehension syntax, which are just as functional as eg. map and filter. So I don't think it is functional constructs in general he is against, but rather specifically the lispy idioms with map, filter etc. with functions/lambdas as arguments.

Decorators are another example of functional programming added to Python, but with a pythonic syntax.

Python supports both imperative, OO and functional idioms, but generally only prefers one of them for a specific task. For example loops are preferred to recursive functions when appropriate. Objects are preferred to closures for mutable state, so mutation of captures variables has not been supported (support have been added recently with nonlocal, but it has clearly not been a priority).

Python is interesting because it is multiparadigm while trying to avoid fragmentation where you can solve the same problem in totally different styles.

Re: Functional programming in Python

#52

Post by gbog »

ubernostrum wrote: post #50
gbog wrote: post #44

Earlier quoted context omitted.

I don't know. It seems to me, from reading SICP, that functional programming doesn't mean lambdas or map reduce, it means pure functions as the main programming unit, instead of object or instruction or declaration. Then it is possible to write functional code in python without lambdas, map, using streams (iterators) as the state keeping data structure.

The problem, as always in these discussions, is that no-one wants to define the term "functional programming". Many people will be quite willing, though, to jump on each other for saying things that they believe flow from an incorrect definition of the term. Anyway, at the very least there's two camps. On the one side, you have the hardcore Scheme folks whose conception of functional programming is "if I can't figure…

Maybe there is a difference between functional programming and functional programming languages.

Re: Functional programming in Python

#53

Post by gbog »

chimeracoder wrote: post #30
andreasvc wrote: post #24

Earlier quoted context omitted.

There's in-place .sort() and the functional sorted(), which has been there since at least 2.6. There's no in-place map, but it would be a one-line function (and you could use map as an in-place operator if you use a function for its side-effects). In the case of + there's the in-place counterpart += (same as extend for lists). So I don't really get your concern, plus mutability is a property of data-structures, not o…

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

Re: Functional programming in Python

#54

Post by ericmoritz »

SiVal wrote: post #41
dustingetz wrote: post #21

as has been pointed out, python isn't particularly great at doing hardcore functional programming due to lack of native persistant datastructures. however i've found it great for learning functional programming without having to get used to the syntax of real functional languages. here are some different ways to implement functional sequence operations without native python syntax like `yield`: https://github.com/dus…

I was at a Python user group meeting with Guido a few years back, and I asked him about his plans for functional programming support in Python. He responded that he thought functional programming was a lot less useful than all the hype would suggest, and that, far from planning more support for functional programming, he regretted having put in as much support as he already had. Ideally, he said, he would remove thin…

I wish he would add TCE for the sole fact that parsing tree like structures feels much more natural using recursion than it does with a for loop. I am always paranoid that a really deep structure will cause an stack depth exceeded exception.

There's a quote from Guido about private attribute access where he said, "We're all adults", and that leaving the open is beneficial.

Recursion is another tool that he should let us adults use if it solves a problem better and TCE is lovely feature to have. Frankly, if you're using recursion, you either just learned it in a CompSci class or you know what you're doing. Either way, daddy Guido shouldn't tell us no :).

Re: Functional programming in Python

#55

Post by olavk »

ubernostrum wrote: post #50
gbog wrote: post #44

Earlier quoted context omitted.

I don't know. It seems to me, from reading SICP, that functional programming doesn't mean lambdas or map reduce, it means pure functions as the main programming unit, instead of object or instruction or declaration. Then it is possible to write functional code in python without lambdas, map, using streams (iterators) as the state keeping data structure.

The problem, as always in these discussions, is that no-one wants to define the term "functional programming". Many people will be quite willing, though, to jump on each other for saying things that they believe flow from an incorrect definition of the term. Anyway, at the very least there's two camps. On the one side, you have the hardcore Scheme folks whose conception of functional programming is "if I can't figure…

Same thing happened with OO, where people have been discussing whether C++ or JavaScript or Python or Smalltalk are "real OO", rather than discussing if the patterns they support are useful or not.

Re: Functional programming in Python

#56

Post by lucian1900 »

ericmoritz wrote: post #54
SiVal wrote: post #41

Earlier quoted context omitted.

I was at a Python user group meeting with Guido a few years back, and I asked him about his plans for functional programming support in Python. He responded that he thought functional programming was a lot less useful than all the hype would suggest, and that, far from planning more support for functional programming, he regretted having put in as much support as he already had. Ideally, he said, he would remove thin…

I wish he would add TCE for the sole fact that parsing tree like structures feels much more natural using recursion than it does with a for loop. I am always paranoid that a really deep structure will cause an stack depth exceeded exception. There's a quote from Guido about private attribute access where he said, "We're all adults", and that leaving the open is beneficial. Recursion is another tool that he should let…

You can use an explicit trampoline to make sure you don't block the stack. It's not as clean, but still better than loops.

Re: Functional programming in Python

#57

Post by soc88 »

lihaoyi wrote: post #42
nknight wrote: post #34

Earlier quoted context omitted.

How do you intend to "update" an immutable list? Isn't it... immutable?

Immutable lists can be preppended/popped in O(1)time, without affecting previous versions. Immutable dicts can have stuff added and removed in O(log n) time, without affecting previous versions. Scala's immutable vectors can have appending/prepending/concatenation/splitting/insertion/deletion in O(log n) time, without affecting previous versions. it's log base 32, so for any arrays using integer indexes, it'll never…

The Scala stuff is impressive. Updated docs at the new site: http://docs.scala-lang.org/overviews/collections/performance...

The new ConcurrentTrie is also a great addition to 2.10.

Re: Functional programming in Python

#58

Post by sureshv »

lihaoyi wrote: post #42
nknight wrote: post #34

Earlier quoted context omitted.

How do you intend to "update" an immutable list? Isn't it... immutable?

Immutable lists can be preppended/popped in O(1)time, without affecting previous versions. Immutable dicts can have stuff added and removed in O(log n) time, without affecting previous versions. Scala's immutable vectors can have appending/prepending/concatenation/splitting/insertion/deletion in O(log n) time, without affecting previous versions. it's log base 32, so for any arrays using integer indexes, it'll never…

There's still a lookup hit of log-b32n versus contiguous memory immutable vector with O(1). Locality can also an issue with tree-like structures but muted with the large branch factor. Of course the flip side scala gives you the kitchen sink for persistance.

Re: Functional programming in Python

#60

Post by soc88 »

chimeracoder wrote: post #10
pepijndevos wrote: post #4

What is really missing is a set of decent data structures.

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?
Post reply on HN