Functools.partial extension to support specific positional arguments

Ideas
24

Maybe the problem is in the DSL part? What if functools.partial could bind positional arguments in standard library functions like it can with user-defined ones without raising a TypeError, would that be a problem?

seconds_to_minutes = partial(divmod, y=60)
25

To be clear, in my previous comment I wasn’t advocating for including better-partial (as it is currently implemented) in the standard library, rather for functions created via def to support a placeholder-like partial application syntax as a language feature.

I work a lot in a functional framework and I frequently run into situations where something like the syntax in better-partial would be useful.

1 Like
26

Maybe a good solution for the specific case in Functools.partial extension to support specific positional arguments - #3 by AndersMunch (which is the one that led me here) is to actually support kwargs in that function (and possibly others in the stdlib that surprisingly don’t support them).

I say that because the natural way of solving this was (for me):

strptime_tpo = partial(datetime.strptime, format="%d/%m/%Y")

And then the failure was:

TypeError: strptime() takes no keyword arguments

Which is itself kinda weird, as almost any function in python supports keyword args automatically.

1 Like
27

I follow the rationale for leaving functools.partial alone, but
there is a specific awkwardness that I haven’t seen highlighted:

Suppose I have a function:

def foo(a, b):
    ...

As a caller I can choose foo(3,4) or foo(a=3, b=4) based on terseness vs clarity.

However, I cannot choose between partial(foo, 3) and partial(foo, a=3).
The latter result cannot be called positionally, so it hasn’t returned a
full-fledged partially bound version of foo. This isn’t obvious.

3 Likes