On Fri, Jun 8, 2012 at 2:04 PM, Yury Selivanov <yselivanov...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
