Between this an fn.py (https://github.com/kachayev/fn.py), functional programming in Python has really good library support beyond the standard library.
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.
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...
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.
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.
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))
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.
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.
agreed. i'm not sure why one would choose to implement an inadequate function here over against something like nltk
(http://www.nltk.org/book/), which is excellent.
Tangential but ... could someone give me the name of the python library that made the front page last month and that "extends the standard lib" (itertools recipes, dates helper functions, etc)?
Can't find it using HN search.
Email in my profile. thks
It is sometimes hard to justify a dependency - many of toolz/fn.py/funcy functions are not hard to write manually.
The great thing about toolz is its https://github.com/pytoolz/cytoolz counterpart which provides an optimized implementation of toolz. It is useful when you have a bottleneck in Python code - e.g. run several functions (functoolz.juxt), merge dictionaries (dicttooz.merge), etc. With cytoolz the code becomes prettier and faster, not only prettier, so it is easier for cytoolz to sneak in.
It seems to me that if you want functional programming, you choose a functional language. You don't (excuse my language) bastardize an OO language for it.
I love stuff like this, though I feel it makes the code actually harder to read because none of it's standardized and there are a variety of somewhat equivalent but not completely isomorphic libraries out there for functional programming in Python.
29 comments
[ 2.4 ms ] story [ 72.2 ms ] threadI 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...
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.
Side note: I already had to write or copy/paste most of the function of pytoolz already once at least.
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))
http://en.m.wikipedia.org/wiki/Stemming
https://news.ycombinator.com/item?id=9350562
The great thing about toolz is its https://github.com/pytoolz/cytoolz counterpart which provides an optimized implementation of toolz. It is useful when you have a bottleneck in Python code - e.g. run several functions (functoolz.juxt), merge dictionaries (dicttooz.merge), etc. With cytoolz the code becomes prettier and faster, not only prettier, so it is easier for cytoolz to sneak in.
http://www.reddit.com/r/Python/comments/1wrlji/
In [1]: data = [{'a': {'b': 1}}, {'a': {'c': 2}}]
In [2]: from toolz import merge, merge_with
In [3]: merge_with(merge, data) Out[3]: {'a': {'b': 1, 'c': 2}}
You'd have to be a bit clever to go fully recursive