cgrimm1994

Excited to be out of stealth!

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.

No worries!

I'm glad you like the recipe :-)

What if you have a function "f" that takes like 10 arguments and you need to pass it to a function "g" that expects as input a function takes 8 arguments.

  @partial
  def f(p1, p2, p3, p4, p5, p6, p7, p8, p9, p10):
     return "stuff"
  
  g(f(..., p4=1, p7=2))
  #  seems nicer than
  g(lambda p1, p2, p3, p5, p6, p8, p9, p10: f(p1, p2, p3, 1, p5, p6, 2, p8, p9, p10))

Yes! I definitely need to beef up the README. I wrote up a gist for some other commenters below which I can incorporate as part of the justification.

https://gist.github.com/chrisgrimm/64bca66f14528cfda6d865cc2...

I'll give this a look.

High praise :-) I'm glad you like it! I don't know much about static checks / param hinting. TBH, I coded this up because I wanted to imagine how functions should work in Python as more of a fun exercise.

Accordingly there are a lot of things I have to do to make better_partial a strong tool for the community. I'll probably have time to work on the project again later in the week.

I'm glad you like it! This project was basically me trying to visualize how I wish functions generally worked like in Python.

I posted this below, but I can put it here too:

https://gist.github.com/chrisgrimm/64bca66f14528cfda6d865cc2...

Essentially functools.partial is somewhat limited in terms of which arguments can be partially applied.

Sure, I'm not claiming to have originated the idea of using _ or some other placeholder to return partially applied functions. Lots of languages have some kind of shorthand syntax for this. I just hadn't seen it done in Python before.

Coconut looks cool btw! I'll give it a closer look soon.

:-)

Thanks for the feedback! This project was really me just imagining how I'd like functions to behave in Python. I didn't really expect there to be this much interest.

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.

I'll look into this soon. I honestly wasn't expecting this much traffic on what essentially was a weekend project, so I'll need to spend a bit of time making the code less insane and testing for things like pickle-ability.

I'm glad you like it! I agree it's not optimal to have to wrap existing functions. One option would be to decorate the functions as they're defined, although you cant do this for external functions.

In my perfect world, python functions would default to behaving as they do when decorated with better_partial.partial, but it seems like a long-shot to try to get something like this added to the language itself.

I guess it depends what kind of stuff you're working on. I do a lot of work with jax for my research (https://github.com/google/jax) and use functools.partial a lot.

Thanks! I would love to see it baked in as well. It'd be nice if, (1) all functions defaulted to behaving like better_partial.partial decorated functions and (2) similar to Ellipsis, there was some other special sentinel that we could use in place of _ (to avoid conflicting with the convention of using _ for unused variables).

As pointed out, you could import _ directly into your namespace, or map it to some other shorthand name that doesn't interfere with your naming conventions.

Also note that the _ placeholder isn't the only way that better_partial helps you. You can also use ... to indicate that you want to omit all arguments except ones you explicitly pass as kwargs. For instance:

  from better_partial import partial, _

  @partial
  def f(a,b,c,d,e):
    return (a,b,c,d,e)
  
  f(_,_,3,_,_)(1,2,4,5) == f(..., c=3)(1,2,4,5)

One option would be to wrap the functions

  from lib import external
  from better_partial import partial as pp, _
  pp(external)(..., arg4=10)

I really appreciate that :) Definitely give it a spin and let me know what you think!

here's an example of one of the behaviors of functools.partial that I find unintuitive / undesirable:

https://gist.github.com/chrisgrimm/64bca66f14528cfda6d865cc2...

Hey, I use functools.partial a lot in my projects and I've always felt like it was pretty limited in the types of partial function application it could accomplish. I put together a modified version of partial over the weekend that I wanted to share / get feedback on. Let me know what you all think!