[Python-ideas] functools.partial

[Nick Coghlan]

(Added list back to recipients)

On Sat, Jun 9, 2012 at 10:58 AM, Devin Jeanpierre
<jeanpierreda at gmail.com> wrote:
> On Fri, Jun 8, 2012 at 8:17 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Speed, complexity and backwards compatibility. With a layered API, users can
>> choose whether they want to do early checks or not. If we build it in, you
>> can't avoid it when you prefer the delayed error to checking the arguments
>> twice.
>
> Then maybe the layered API belongs in the stdlib. What's the use of
> base partial type, except as a micro-optimization?

functools.partial will still be used to change the signature of a
callable, the same as it has been ever since it was added. The layered
API runs afoul of "not every three line function needs to be in the
standard library". It's better to add the base API that is difficult
for third parties to provide (in this case, inspect.signature and
Signature objects) and let specific use cases emerge naturally over
time, rather than trying to guess the *exact* patterns in advance.

> On the other hand, I'm not so sure about your complexity argument.
> It's hard to argue against "this isn't worth our time", if that's what
> you're saying. But if you're saying it's too complicated now,
> shouldn't Signature.bind help with that?

I'm saying it makes *functools.partial* more complex, because we're
asking it to do more. We would also be making it impossible to use
without checking every signature twice. Current uses will be a mix of
cases where the lack of early checking is annoying (but tolerable) and
cases where it is undesirable. Adding the checking directly to the
base API means we're assuming that early checking is desirable for
*every* use case, and that's unlikely to be true.

Most importantly though, if we leave the status quo in place for now,
we can change our minds later if we still think it's a good idea. If
we charge ahead and add early checking everywhere immediately, then
we're quite likely to do more harm than good.

We're in this for the long haul, and 2014 really isn't that far away
in the context of programming language evolution.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia