On Wed, Jun 20, 2012 at 11:22 AM, Yury Selivanov <yselivanov...@gmail.com> wrote: > On 2012-06-19, at 8:39 PM, Nick Coghlan wrote: >> 6. I think "return_annotation" can safely be abbreviated to just >> "annotation". The fact it is on the Signature object rather than an >> individual parameter is enough to identify it as the return >> annotation. > > I'm not sure about this one. 'return_annotation' is a very > self-descriptive and clear name.
I'm not too worried about that one. If you prefer the longer name, feel free to keep it. >> If we even keep that at all for the initial version of the API, the >> direct "default" and "annotation" attributes would just be read-only >> properties that accessed the "optional" container (reporting >> AttributeError if the corresponding attribute was missing) > > +0. I think that 'optional' is a bit unusual attribute for the stdlib, > but it will work if we make Signature immutable. The name isn't great, but the mapping is a lot more convenient when you need to handle the case of attributes potentially being missing. >> 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. >> 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) 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