4 ms·

I love libraries like this and fn.py, and I really miss the things I've got used to having available in Haskell when I write python. It's possible to use functi

I love libraries like this and fn.py, and I really miss the things I've got used to having available in Haskell when I write python. It's possible to use function patterns in python (Applicative and Functor are things you can implement in any language). However given who is in charge of python and the way he feels about FP, I don't think python will ever be a decent functional programming environment: As long as I'm "in charge" the chances of this (or anything like it) being accepted into Python are zero. I get a headache when I try to understand code that uses function composition, and I end up having to laboriously rewrite it using more traditional call notation before I move on to understanding what it actually does. Python is not Haskell, and perhaps more importantly, Python users are not like Haskell users. Either way, what may work out beautifully in Haskell will be like a fish out of water in Python. I understand that it's fun to try to sole this puzzle, but evolving Python is more than solving puzzles. Enjoy debating the puzzle, but in the end Python will survive without the solution. http://stackoverflow.com/questions/1017621/why-isnt-python-very-good-for-functional-programming http://stackoverflow.com/questions/1017621/why-isnt-python-v...

scardine 11y ago
Function call is somewhat expensive in Python compared to most languages, so I guess there are reasons other than personal taste for why functional composition is not blessed.
imakesnowflakes 11y ago
I just hope he (and his successors) maintain the same uncompromisingly critical approach when it comes to adding features to the language.. I think the lack of some things like this, is a sort of reminder to the programmer that says, "hey you, you are writing Python. Not Haskell. Do not go that way because we don't have stuff to deal with what you may find further down that road". Nothing ruins a language like adding a bunch of poorly thought out half baked features, that does not fit well with the rest of it...
- boothead 11y ago
  And yet a language has to evolve or become obsolete...
  - toyg 11y ago
    I would argue that the really necessary evolution is often in implementation facilities, rather than core language constructs. C++ has evolved more than most, but people who don't choose C++ do it mostly because of other considerations. You could have the most functional C++ version ever, and still people would not use it for simple web apps.
  - ubernostrum 11y ago
    Which is not the same as "a language must evolve into my preferred design or become obsolete". Python has made it through years of criticism from people who misunderstand Guido's stance on FP in Python (and before that from people who disliked his stance on tail call optimization) without being obsoleted by pure FP languages.
  - afarrell 11y ago
    Which, like apoptosis, is eventually a good thing.
amirouche 11y ago
It seems to me function composition does similar thing as inheritance. I don't know about other (more higher?) functionnal patterns. Side note: I already had to write or copy/paste most of the function of pytoolz already once at least.
- boothead 11y ago
  Not really - but it does let you chunk functionality together from smaller pieces. So if you have function f1 that takes a and returns b (a -> b) and a function f2 that takes b and returns c (b -> c) you can compose them into a function (a -> c) all it does is call f2(f1(a))
- agumonkey 11y ago
  Inheritance is quite heavy and static. FP idioms are full of tiny combinators to assemble pieces of logic to suit your needs, flip/reorder parameters, "cache" them through partial application. The historical reusable code that OOP claimed through the 90s seems much more real using FP. OOP is too verbose and too name-friendly, people create lots of classes not abstract enough to be used anywhere else, closer to concrete types than abstractions.

scardine 11y ago

Function call is somewhat expensive in Python compared to most languages, so I guess there are reasons other than personal taste for why functional composition is not blessed.

imakesnowflakes 11y ago

I just hope he (and his successors) maintain the same uncompromisingly critical approach when it comes to adding features to the language.. I think the lack of some things like this, is a sort of reminder to the programmer that says, "hey you, you are writing Python. Not Haskell. Do not go that way because we don't have stuff to deal with what you may find further down that road". Nothing ruins a language like adding a bunch of poorly thought out half baked features, that does not fit well with the rest of it...

boothead 11y ago
And yet a language has to evolve or become obsolete...
- toyg 11y ago
  I would argue that the really necessary evolution is often in implementation facilities, rather than core language constructs. C++ has evolved more than most, but people who don't choose C++ do it mostly because of other considerations. You could have the most functional C++ version ever, and still people would not use it for simple web apps.
- ubernostrum 11y ago
  Which is not the same as "a language must evolve into my preferred design or become obsolete". Python has made it through years of criticism from people who misunderstand Guido's stance on FP in Python (and before that from people who disliked his stance on tail call optimization) without being obsoleted by pure FP languages.
- afarrell 11y ago
  Which, like apoptosis, is eventually a good thing.

amirouche 11y ago

It seems to me function composition does similar thing as inheritance. I don't know about other (more higher?) functionnal patterns. Side note: I already had to write or copy/paste most of the function of pytoolz already once at least.

boothead 11y ago
Not really - but it does let you chunk functionality together from smaller pieces. So if you have function f1 that takes a and returns b (a -> b) and a function f2 that takes b and returns c (b -> c) you can compose them into a function (a -> c) all it does is call f2(f1(a))
agumonkey 11y ago
Inheritance is quite heavy and static. FP idioms are full of tiny combinators to assemble pieces of logic to suit your needs, flip/reorder parameters, "cache" them through partial application. The historical reusable code that OOP claimed through the 90s seems much more real using FP. OOP is too verbose and too name-friendly, people create lots of classes not abstract enough to be used anywhere else, closer to concrete types than abstractions.