[Python-Dev] pep 362 - 5th edition

[Yury Selivanov]

On 2012-06-19, at 10:16 PM, Nick Coghlan wrote:

> On Wed, Jun 20, 2012 at 11:22 AM, Yury Selivanov
> <yselivanov.ml at 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