(Added list back to recipients) On Sat, Jun 9, 2012 at 10:58 AM, Devin Jeanpierre <jeanpierreda@gmail.com> wrote:

On Fri, Jun 8, 2012 at 8:17 PM, Nick Coghlan <ncoghlan@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@gmail.com   |   Brisbane, Australia