Hello, While I was working on adding support for 'functools.partial' in PEP 362, I discovered that it doesn't do any sanity check on passed arguments upon creation. Example: def foo(a): pass p = partial(foo, 1, 2, 3) # this line will execute p() # this line will fail Is it a bug? Or is it a feature, because we deliberately don't do any checks because of performance issues? If the latter - I think it should be at least documented. - Yury
On Fri, Jun 8, 2012 at 12:57 PM, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
Partly the latter, but also a matter of "this is hard to do, so we don't even try". There are many other "lazy execution" APIs with the same problem - they accept an arbitrary underlying callable, but you don't find out until you try to call it that the arguments don't match the parameters. This leads to errors being raised far away from the code that actually introduced the error. If you dig up some of the older PEP 362 discussions, you'll find that allowing developers to reduce this problem over time is the main reason the Signature.bind() method was added to the PEP. While I wouldn't recommend it for the base partial type, I could easily see someone using PEP 362 to create a "checked partial" that ensures arguments are valid as they get passed in rather than leaving the validation until the call is actually made. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Jun 9, 2012 6:08 AM, "Devin Jeanpierre" <jeanpierreda@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. Cheers, Nick. -- Sent from my phone, thus the relative brevity :)
-- Devin
On Fri, Jun 8, 2012 at 12:57 PM, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
Partly the latter, but also a matter of "this is hard to do, so we don't even try". There are many other "lazy execution" APIs with the same problem - they accept an arbitrary underlying callable, but you don't find out until you try to call it that the arguments don't match the parameters. This leads to errors being raised far away from the code that actually introduced the error. If you dig up some of the older PEP 362 discussions, you'll find that allowing developers to reduce this problem over time is the main reason the Signature.bind() method was added to the PEP. While I wouldn't recommend it for the base partial type, I could easily see someone using PEP 362 to create a "checked partial" that ensures arguments are valid as they get passed in rather than leaving the validation until the call is actually made. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Jun 9, 2012 6:08 AM, "Devin Jeanpierre" <jeanpierreda@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. Cheers, Nick. -- Sent from my phone, thus the relative brevity :)
-- Devin
participants (3)
-
Devin Jeanpierre -
Nick Coghlan -
Yury Selivanov