9 ms·

Currying in Python

53 points by Luyt 15y ago

sudhirj 15y ago
There's also a complementary article I wrote last year on http://hangar.runway7.net/partial-functions-in-python http://hangar.runway7.net/partial-functions-in-python
lloeki 15y ago
nitpick: camelCase burns my eyes on functions and vars in Python code, and since that's not PEP8 compliant it makes syntastic shout at me when torturing your examples in vim.
prezjordan 15y ago
I love the Haskell implementation, since arguments and functions don't need any discernible characters, f 1 2 3 4 5 works just fine. I guess this was one of the original design features of Haskell.
- Drbble 15y ago
  Yup. The tradeoff is that you lose multiple dispatch based on argument list size (overloading) (Clojure, C++, and Java takes the other side of that tradeoff. I don't know if Python has signature-overloading like that.)
  - rplnt 15y ago
    I don't think python has any sort of overloading (based on signature that is). You can use def f(°args, °°kwargs) though. What you'll get is a tuple containing positional arguments and dictionary with keywords arguments. You can even specify some explicitly and then consume all others with this. edit: ° should've been * but I couldn't escape it without using spaces.
kbd 15y ago
I'm glad he made the correct distinction between partial application and currying. The article is worth it for his helpful explanation of the two alone. Though, it's slightly off on the initial presentation of currying. Currying is the act of transforming a function that takes multiple arguments into a function that returns a function that takes n-1 arguments, and so on, not an "incremental binding of function arguments".
- Drbble 15y ago
  I don't see a meaningful difference in the cases in your last paragraph. Seems like an implementation detail. The issue of whether the caller has to explicitly call "partial" seems to be the meaningful distinction.
  - deleted 15y ago
    [deleted]
  - wildanimal 15y ago
    The original statement could be interpreted in this way: the former operation 'returns a function' and in the latter, it 'bind[s] [...] arguments' - suggesting a form of destructive updating of the original function. But I agree with you that in this context, since both return functions it's an implementation detail.
Drbble 15y ago
Ha, I write my Javascript like this. Makes me want to just go back to Haskell though. Does currying kill performance in Python like it does in Javascript? To reduce clutter and unobscure the point, and support uncurried usage (like apply(f, args) however that is done in Python) , it needs more lambdas instead, of defs: f = lambda a: lambda b: f_uncurried(a, b)
- kbd 15y ago
  > like apply(f, args) however that is done in Python Python 2 has an apply function [1], but it was deprecated for a long time and removed in 3.0 [2]. apply(f, args) is equivalent to f(*args) in Python. [1] http://docs.python.org/library/functions.html#apply http://docs.python.org/library/functions.html#apply [2] http://docs.python.org/release/3.0.1/whatsnew/3.0.html#builtins http://docs.python.org/release/3.0.1/whatsnew/3.0.html#built...
dustingetz 15y ago
look, Python's audience isn't Haskell's audience, and all these scary words like "curring", "incremental binding", "just like haskell", "left association" aren't things that most Python people care about. the article makes this stuff look like voodoo which is frustrating because functional programming doesn't have to be voodoo. currying is really really easy and everyday python programmers probably do it on accident. def divisible(n, x): return n % x == 0 def divisors(n): possible_divisors = range(2, int(sqrt(n))+1) return filter(lambda x: divisible(n, x), possible_divisors) # OMG curry ! assert divisors(24) == [2, 3, 4]
- tmhedberg 15y ago
  This argument seems silly to me. Currying is the name of the technique. Why is that scary? Should he call it something different just to avoid "scaring" feeble programmers who are afraid of new words?
  - joejohnson 15y ago
    No, but he could introduce a new topic (Currying), and then instead of showing how it's "just like Haskell" (something his target audience might not care about), he could instead show how it's another way of thinking about something that most programmers probably already do.
  - anamax 15y ago
    You're missing the point. Currying isn't a big deal for python programmers. The article fails precisely because it makes currying into a big deal. This is yet another example of how haskell got it wrong. Currying isn't something that one should do all the time or think about, so basing a language on it is dumb. (And that's true even if we ignore the complications that it adds to polymorphism.)
    - tkahn6 15y ago
      > Currying isn't something that one should do all the time or think about, so basing a language on it is dumb. Can you elaborate on what you mean by this? As it stands I don't understand what this means. > (And that's true even if we ignore the complications that it adds to polymorphism.) Please elaborate on this as well.

53 points by Luyt 15y ago

There's also a complementary article I wrote last year on http://hangar.runway7.net/partial-functions-in-python http://hangar.runway7.net/partial-functions-in-python

lloeki 15y ago

nitpick: camelCase burns my eyes on functions and vars in Python code, and since that's not PEP8 compliant it makes syntastic shout at me when torturing your examples in vim.

prezjordan 15y ago

I love the Haskell implementation, since arguments and functions don't need any discernible characters, f 1 2 3 4 5 works just fine. I guess this was one of the original design features of Haskell.

Drbble 15y ago
Yup. The tradeoff is that you lose multiple dispatch based on argument list size (overloading) (Clojure, C++, and Java takes the other side of that tradeoff. I don't know if Python has signature-overloading like that.)
- rplnt 15y ago
  I don't think python has any sort of overloading (based on signature that is). You can use def f(°args, °°kwargs) though. What you'll get is a tuple containing positional arguments and dictionary with keywords arguments. You can even specify some explicitly and then consume all others with this. edit: ° should've been * but I couldn't escape it without using spaces.

kbd 15y ago

I'm glad he made the correct distinction between partial application and currying. The article is worth it for his helpful explanation of the two alone. Though, it's slightly off on the initial presentation of currying. Currying is the act of transforming a function that takes multiple arguments into a function that returns a function that takes n-1 arguments, and so on, not an "incremental binding of function arguments".

Drbble 15y ago
I don't see a meaningful difference in the cases in your last paragraph. Seems like an implementation detail. The issue of whether the caller has to explicitly call "partial" seems to be the meaningful distinction.
- deleted 15y ago
  [deleted]
- wildanimal 15y ago
  The original statement could be interpreted in this way: the former operation 'returns a function' and in the latter, it 'bind[s] [...] arguments' - suggesting a form of destructive updating of the original function. But I agree with you that in this context, since both return functions it's an implementation detail.

Drbble 15y ago

Ha, I write my Javascript like this. Makes me want to just go back to Haskell though. Does currying kill performance in Python like it does in Javascript? To reduce clutter and unobscure the point, and support uncurried usage (like apply(f, args) however that is done in Python) , it needs more lambdas instead, of defs: f = lambda a: lambda b: f_uncurried(a, b)

kbd 15y ago
> like apply(f, args) however that is done in Python Python 2 has an apply function [1], but it was deprecated for a long time and removed in 3.0 [2]. apply(f, args) is equivalent to f(*args) in Python. [1] http://docs.python.org/library/functions.html#apply http://docs.python.org/library/functions.html#apply [2] http://docs.python.org/release/3.0.1/whatsnew/3.0.html#builtins http://docs.python.org/release/3.0.1/whatsnew/3.0.html#built...

dustingetz 15y ago

look, Python's audience isn't Haskell's audience, and all these scary words like "curring", "incremental binding", "just like haskell", "left association" aren't things that most Python people care about. the article makes this stuff look like voodoo which is frustrating because functional programming doesn't have to be voodoo. currying is really really easy and everyday python programmers probably do it on accident. def divisible(n, x): return n % x == 0 def divisors(n): possible_divisors = range(2, int(sqrt(n))+1) return filter(lambda x: divisible(n, x), possible_divisors) # OMG curry ! assert divisors(24) == [2, 3, 4]

tmhedberg 15y ago
This argument seems silly to me. Currying is the name of the technique. Why is that scary? Should he call it something different just to avoid "scaring" feeble programmers who are afraid of new words?
- joejohnson 15y ago
  No, but he could introduce a new topic (Currying), and then instead of showing how it's "just like Haskell" (something his target audience might not care about), he could instead show how it's another way of thinking about something that most programmers probably already do.
- anamax 15y ago
  You're missing the point. Currying isn't a big deal for python programmers. The article fails precisely because it makes currying into a big deal. This is yet another example of how haskell got it wrong. Currying isn't something that one should do all the time or think about, so basing a language on it is dumb. (And that's true even if we ignore the complications that it adds to polymorphism.)
  - tkahn6 15y ago
    > Currying isn't something that one should do all the time or think about, so basing a language on it is dumb. Can you elaborate on what you mean by this? As it stands I don't understand what this means. > (And that's true even if we ignore the complications that it adds to polymorphism.) Please elaborate on this as well.