4 ms·

https://toolz.readthedocs.io/en/latest/curry.html https://toolz.readthedocs.io/en/latest/curry.html

seanhunter 5y ago
This is a bit of a personal bugbear, but partial function application is not currying. I wrote a blog post on this a while ago because it's such a common misconception. https://www.uncarved.com/articles/not-currying/ https://www.uncarved.com/articles/not-currying/ The link you posted is just using the word wrong. Currying is not syntactic sugar for partial application, it is the opposite. (ie currying builds functions which take multiple arguments from chains of functions which each take a single argument)
- cgrimm1994 5y ago
  Yes! I almost made this mistake. Although I'm not sure @partial is the most apt name for the decorator, as it produces a function which can be partially applied. In retrospect, @partialize or something like it might be more appropriate.
- d0mine 5y ago
  @curryable looks the same as @partializable: @curryable def add(a, b): return a+b add2 = add(..., 2) # curried print(add2(3)) # 5
  - cgrimm1994 5y ago
    I think the similarity ends when you consider functions with more than 2 arguments. Let's compare a 2 argument function with a 3 argument function: @partial def f3(x, y, z): return (x, y, z) @partial def f2(x, y): return (x, y) A curried version of f2 would look like: curried_f2 = lambda x: lambda y: f2(x, y) curried_f2(1)(2) == (1, 2) Currying produces a chain of functions which each take one argument. So its true for f2 that currying and the partial decorator are similar: curried_f2(1) == f2(1, _) == f2(..., x=1) as you pointed out. But now consider the 3 argument case: curried_f3 = lambda x: lambda y: lambda z: f3(x, y, z) curried_f3(1) != f3(1, _, _) this is because f(1, _, _) takes two arguments whereas curried_f3(1) takes one.
    - d0mine 5y ago
      It doesn't look natural to me nesting one arg functions in Python: lambda x: lambda y: lambda z: .. What would the harm be to adapt the abstract notion (curry) for the specific language instead of trying to apply it literally (ugly)? For example, I remember the notion of iteration is introduced in SICP using the syntax that were it to be translated literally into Python would look like recursive calls— obviously it would be unnatural to represent iterations this way in Python.

This is a bit of a personal bugbear, but partial function application is not currying. I wrote a blog post on this a while ago because it's such a common misconception. https://www.uncarved.com/articles/not-currying/ https://www.uncarved.com/articles/not-currying/ The link you posted is just using the word wrong. Currying is not syntactic sugar for partial application, it is the opposite. (ie currying builds functions which take multiple arguments from chains of functions which each take a single argument)

cgrimm1994 5y ago
Yes! I almost made this mistake. Although I'm not sure @partial is the most apt name for the decorator, as it produces a function which can be partially applied. In retrospect, @partialize or something like it might be more appropriate.
d0mine 5y ago
@curryable looks the same as @partializable: @curryable def add(a, b): return a+b add2 = add(..., 2) # curried print(add2(3)) # 5
- cgrimm1994 5y ago
  I think the similarity ends when you consider functions with more than 2 arguments. Let's compare a 2 argument function with a 3 argument function: @partial def f3(x, y, z): return (x, y, z) @partial def f2(x, y): return (x, y) A curried version of f2 would look like: curried_f2 = lambda x: lambda y: f2(x, y) curried_f2(1)(2) == (1, 2) Currying produces a chain of functions which each take one argument. So its true for f2 that currying and the partial decorator are similar: curried_f2(1) == f2(1, _) == f2(..., x=1) as you pointed out. But now consider the 3 argument case: curried_f3 = lambda x: lambda y: lambda z: f3(x, y, z) curried_f3(1) != f3(1, _, _) this is because f(1, _, _) takes two arguments whereas curried_f3(1) takes one.
  - d0mine 5y ago
    It doesn't look natural to me nesting one arg functions in Python: lambda x: lambda y: lambda z: .. What would the harm be to adapt the abstract notion (curry) for the specific language instead of trying to apply it literally (ugly)? For example, I remember the notion of iteration is introduced in SICP using the syntax that were it to be translated literally into Python would look like recursive calls— obviously it would be unnatural to represent iterations this way in Python.