On 2012-06-19, at 10:16 PM, Nick Coghlan wrote: > On Wed, Jun 20, 2012 at 11:22 AM, Yury Selivanov > <yselivanov...@gmail.com> wrote: >>> 10. Similar to the discussion of convenience properties on Signature >>> objects themselves, I now think we should drop the "args" and "kwargs" >> >> Big -1 on this one. Look at the current implementation of those >> properties - it's quite complex. One of the major points of new >> API is to allow easy modifications of arguments. Without .args & >> .kwargs it will be a PITA to call a function. >> >> Imagine, that the "check types" example from the PEP is modified >> to coerce arguments to specified types. It won't be possible >> to do without .args & .kwargs. I, for instance, use this API to bind, >> validate, and coerce arguments for RPC calls. The whole point for me >> to work on this PEP was to make these types of functionality easy to >> implement. > > The one thing that slightly concerns me is that given: > > def f(a): pass > s = signature(f) > > The following produce the same result: > s.bind(1) > s.bind(a=1) > > That said, I guess if a parameter is proclaiming itself to be > KEYWORD_OR_POSITIONAL, then it really shouldn't care which way the > arguments are passed, so a stated preference for binding those as > positional parameters is fine.
Right. >>> properties from the initial version of BoundArguments. Instead, I >>> propose the following attributes: >>> - arguments (mapping of parameter names to values supplied as arguments) >>> - defaults (mapping of unbound parameter names with defaults to >>> their default values) >> >> Why would you need 'defaults'? It's very easy to compile that list >> manually (and I believe the use cases will be limited) >> >>> - unbound (set of unbound names, always empty for bind(), may have >>> entries for bind_partial()) >> >> This may be practical. But again - those are easy to deduce from >> 'BoundArguments.arguments' and 'Signature.parameters'. > > OK, leave them out for now. Perhaps add a simple example showing how > to calculate them if you want them? (The most obvious use case I can > see is calculating a new signature after using bind_partial) OK, will add an example to the PEP - Yury _______________________________________________ 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
