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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
