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
