[Python-Dev] Updated PEP 362 (Function Signature Object)

Nick Coghlan ncoghlan at gmail.com
Fri Jun 8 06:39:14 CEST 2012


On Fri, Jun 8, 2012 at 2:04 PM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
>>> 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.
>
> It's not going to be that easy with the current PEP design.
>
> In order to add support for partial, I had to split the implementation
> of 'bind' into two functions:
>
>    def _bind(self, args, kwargs, *, partial=False):
>        ...
>
>    def bind(self, *args, **kwargs):
>        return self._bind(args, kwargs)
>
> The first one, '_bind' does all the hard work.  When 'partial' flag
> is False - it performs all possible checks.  But if it's 'True', then
> it allows you to bind arguments in the same way 'functools.partial'
> works, but still with most of the validation.

I would keep _bind() as an implementation detail (because the
signature is ugly), and expose the two behaviours as bind() and
bind_partial() (with the cleaner existing signature).

I thought about suggesting that bind_partial() return a (Signature,
BoundArguments) tuple, but realised that doesn't make sense, since
there are at least two different ways to use bind_partial():
1. to provide or change the default arguments for one or more parameters
2. to remove one or more parameters from the signature (forcing them
to particular values)

Rather than trying to guess specific details on how it could be used a
priori, it makes more sense to just leave it up to the caller to
decide how they want to update the Signature object. If additional
convenience methods seem like a good idea in the future, they can
either be provided in a third party enhanced signature manipulation
library, and/or added in 3.4.

Cheers,
Nick.

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


More information about the Python-Dev mailing list