21–30 of 36 posts
I'd rather see partial() promoted to a universal static method attached to any callable, so it's easier to discover, and use.
My only grief is that decorator, which forces you to wrap existing functions anyway (same way I had to define lambdas in my example anyway).
Do you have any insight on that?
(mtcars >> group_by(_.cyl) >> summarize(avg_hp = _.hp.mean()) )
(Edit: ok, it seems siuba doesn't have the "parameter fixing" thing.)
Related: Coconut - a functional superset of Python - https://github.com/evhub/coconut
range(10) |> map$(pow$(?, 2)) |> list
There were others but I can't remember which now.
I'm sure it is! That's why I'd be leery of using it in production code.
whats wrong with functools.partial? I don't see that anywhere in the arguments.. all you say is "I find functools.partial unintuitive".. why? its a simple wrapper.
https://gist.github.com/chrisgrimm/64bca66f14528cfda6d865cc2...
I like how clever this is. It's a little too clever for production code for my tastes, but it might be nice to use in exploratory programming.
Could this be used without the "bp."? Half the point of coming up with a nicer notation is for the notation to actually be nicer.
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)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!
`functools.partial` has been bothering me for a long time and I've always thought it'd be nice to have something like the placeholder `·` that people use in math (i.e. `f(·, y, z)`). It didn't occur to me that a decorator might actually get us there without having to introduce new syntax. Nice project!
I was gonna say cool for FP guys but alien to the Python world, but then i saw the f(..., x=1) syntax and decided you're a genius. Really nice idea. In practice i worry about static checkers and IDE param hints though, how have you fared with these? Not your fault at all, but mypy/pyright have very poor support for wrappers like this, and in IDEs it's common for their arg hints to devolve to a copout (args, kwargs) a…
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.