[Python-Dev] pep 362 - 5th edition (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Wed Jun 20 04:16:14 CEST 2012

On Wed, Jun 20, 2012 at 11:22 AM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:

On 2012-06-19, at 8:39 PM, Nick Coghlan wrote:

6. I think "returnannotation" 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.  'returnannotation' 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 bindpartial()) 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   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list