[Python-Dev] Partial function application 'from the right'

[Steven D'Aprano]

Raymond Hettinger wrote:

>>> The arguments for and against the patch could be brought against 
>>> partial()
>>> itself, so I don't understand the -1's at all.
>>
>> Quite so, but that doesn't justify adding more capabilities to partial().
> 
> I concur with Collin.  Lever arguments are a road to bloat.

One person's "bloat" is another person's rich and complete toolbox.

 > "In for a penny, in for a pound" is not a language design principle.

Neither are "slippery slope" arguments.

> One of the real problems with partial() and its variants is that they 
> provide almost no advantage over an equivalent lambda.

How about speed? I don't have a recent version of Python here to test, 
but my recollection is that partial is significantly faster than lambda. 
And even if it currently isn't, there could be (is?) more opportunity to 
optimize partial.

I guess that the voting on this is going to be fall along functional 
lines: those who like functional languages will vote +1 on partial and 
co, and those who don't will vote -1.

While I don't dislike partial(), I'd rather see one good use-case for 
partial_right() to be removed: built-ins that don't accept keywords. 
 From Ben North's post starting this thread:

"I find 'functools.partial' useful, but occasionally I'm unable to use 
it because it lacks a 'from the right' version.  E.g., to create a 
function which splits a string on commas, you can't say

    # Won't work when called:
    split_comma = partial(str.split, sep = ',')

and to create a 'log to base 10' function, you can't say

    # Won't work when called:
    log_10 = partial(math.log, base = 10.0)

because str.split and math.log don't take keyword arguments."

I'd argue that it is better to add support for keyword arguments than to 
add partial_right.


-- 
Steven