[Python-Dev] pep 362 - 5th edition

[Nick Coghlan]

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 "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   |   ncoghlan at gmail.com   |   Brisbane, Australia